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ABSTRACT 
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the types of support and function calls that should be pro- 
vided to application programs running on micro computers are 
described with respect to a database resource. The database 
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INTRODUCTION 



I . 

Traditionally, computer software evolved in connection 
with a particular hardware environment, and often assumed 
features closely related to characteristics of the underlying 
hardware. These so-called closed systems usually have a unique 
set of resources in both hardware and software. However, as 
systems became more general purpose, the requirement for porta- 
bility and reusability of resources across systems increased 
and, consequently, the need for creating greater resource 
abstraction arose [Ref. 1] . 

The problem of formalizing the relationship between hardware 
and software resources was first addressed by Yurchak [Ref. 2] 
whose efforts resulted in the specification and implementation 
of an abstract machine, called AM. 

New data types necessary to represent the abstraction of a 
bit-mapped display resource were added to AM by Hunter [Ref. 3] 
thereby creating AM (version 2.0) as a derivation of version 
1 . 0 . 

This present research again is an extension of the work 
begun by Yurchak and Hunter with the goal to design and for- 
mally specify a portable, reusable abstract database (version 
3.0) . Its two major objectives are: 

- investigate an appropriate methodology to specify an 
interface between the layers of computer hardware and 
software ; 



10 



- find a way for applying such a methodology in order to 
describe the interface of a computing system with 
respect to a database. 

% 

The following is a modification of the introduction presented 
by Yurchak [Ref. 2] and Hunter [Ref. 3], and contains some of 
their ideas which contributes to a better understanding of the 
background and motivation for this research. 



A. THE PORTABILITY PROBLEM 

It is well known that porting large programs from one machine 
to another is an expensive ordeal. It is also well known that 
once the software has been moved to the new machine, it is 
anybody's guess whether or not it will be work as before. Even 
if our program seems to work, we may find it consumes more re- 
sources than we expected. Indeed, this may be just as bad as 
if it did not work at all. 

There are a number of -reasons why the portability problem 
is getting worse, not better: 

- most architectures, even those which profess to be 
"language directed," reflect a bias toward making the 
machine look like what the programmer wants, or toward 
some engineering goal, such as maximizing the number of 
devices ; 

- both languages and machines are related to the data they 
manipulate in an implementation dependent way; 

- language and hardware designers pursue their conflicting 
goals to the detriment of the poor compiler writer, who, 
with imprecise tools and methodologies is faced with 
the job of implementing ambiguous semantics on an 
informally designed resource. 

Although these and other factors do adversely contribute to 
the imperfect task of moving software from one machine to 
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another, they add their weight to other difficult issues in 
language design, computer architecture, and software engineer- 
ing. This study confines itself to treating the issues surround- 
ing the interaction between programmer's view of the world as 
a problem, and the architect's view of the world as a resource. 

The existing problem can widely be described as a matter 
of unsufficient resource abstraction. And there are examples 
that demonstrate the advantages brought along by consequently 
applied resource abstraction. For instance, many operating 
systems (OS) already provide a uniform and functional interface 
to the file system, and combined with a high level language and 
its associated runtime services, achieve a high degree of soft- 
ware portability [Ref. 1]. Current research work in the area 
of database machines indicates attempts to develop a system that 
would, like the OS, provide a uniform interface, the first step 
towards portability and reusability. And this trend should give 
some reason to be a little more optimistic. 

1 . Abstraction 

"Abstraction" describes the separation of the defining 
properties of an object from other, unnecessary details about 
it. A programmer is primarily concerned with solving a prob- 
lem. Appropriately, the tools at his disposal, programming 
languages, development aids, the programming environment, form 
a "problem solving abstraction." The hardware (and some of 
the software) on which this problem solving abstraction is 
implemented, however, is an abstraction of a different sort. 
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Addresses, registers, ports, most of the operating system 
service routines, all provide more or less efficient ways to 
manipulate the physical resources of the machine, they form a 
"physical resource abstraction." 

The fuzzy area between these two abstractions, sometimes 
simplistically perceived as the boundary between hardware and 
software, exposes a number of shortcomings in language design 
and computer architecture collectively termed the "semantic 
gap. " 

As mentioned before, proper resource abstraction plays 
a major role in the attempt to resolve the portability problem. 
In areas other than the operating systems, abstraction however, 
seems to be rather difficult. Processors and visual displays 
are examples. The inability to establish a meaningful abstrac- 
tion has impeded the formation of standard functional inter- 
faces to these resources. Operating systems generally do not 
provide a functional interface to either the processor or the 
display.'*' Programs which access these resources directly, 
simply are not portable. High level languages (HLL) partially 
fill the gap left by OFs for the processor resource. Unfor- 
tunately, the interface level is high enough to force many 
applications to bypass the HLL for efficiency. Special graphics 
packages that extend the OS provide similar services for the' 
display resource. But despite these efforts, the problem is 

'*'Except in the most rudimentary way, OS function calls to 
the display are usually limited to character and string 
output. 
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still far from solved. The lack of formal means to specify the 
interface that the operating systems, high level languages and 
graphics packages attempt to provide is a serious shortcoming 
that impedes portability. 

The same applies for database systems, too, which al- 
though more recently introduced in computer history not only 
offer a whole set of different and incompatible database models 
from which to choose, but also force the implementor to adopt 
the corresponding query language. The latest development is 
towards the so-called backend approach that reduces the workload 
of the host computer in a very impressive way by separating 
the database part from the mainframe and letting it run as 
autonomously as possible; but the above described interface 
problem remains unsolved. Thus, at present, the variety that 
originally was created to optimize a data base to meet the 
respective goals, strongly interferes with the idea of 
reusability . 

2 . The Semantic Gap 

The semantic gap manifests itself anywhere a problem 
solving abstraction touches a physical resource abstraction. 

A detailed description may be found in Myers [Ref. 4] . He 
observes that the semantic gap contributes to the cost of 
software development, software unreliability, inef f i'ciency , 
complexity, and the distortion of programming languages. Cer- 
tainly- no single development or methodology will eliminate this 
problem. 
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Narrowing the semantic gap requires significant changes 

in the fundamentals of computer architecture and language design. 

% 

We chose to concentrate on three factors which significantly 
contribute to this problem: 

informally described semantics; 
representation dependent data types; 

arbitrarily designed instruction set architectures. 

The implication, of course, is that through increased formalism, 
the introduction of representation independent data, and a more 
throughtful treatment of the instruction set, the semantic gap 
can be narrowed. The balance of this thesis is devoted to 
describing a methodology for doing just that. 

B. THREE WAYS TO NARROW THE SEMANTIC GAP 
1 . Formalism 

The benefits of formalism in the design process have 
been amply revealed in countless articles treating this issue 
from the standpoint of software engineering. Our concern will 
be limited to formalism as it applies to the specification of 
an abstraction. Various specification methodologies exist, 
many of which have been used with more or less success in pro- 
jects of practical significance. But we caution the reader 
that by "formal" we mean a mathematical rigor rooted in proven 
theory. The idea of formalism as often applied to software 
engineering will not do here. A "formal specification" is a 
complete description of the meaning of an object. It forms the 
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basis for an abstraction and is ultimately a bridge over the 
semantic gap. 

The benefits of formalism in which we are most inter- 
ested are: 

it provides a firm basis for proving our assertions 
about a specification and its implementation; 

it encourages a discipline on the part of the designer 
to be rigorously precise; 

it compels us to find ways of describing things which 
are (implementation) independent. 

2 . Representation Independence 

Conventional machines, in contrast to the AM, force 
us, as programmers, to develop our own abstractions of data. 

At a time when we are most concerned with developing clean 
algorithms the architecture obligates us to worry about status 
registers and word length. Certainly someone must ultimately 
deal with these physical properties of the hardware, but this 
should not fall as an "obligation" upon the programmer. The 
programmer should be free to ignore unnecessary detail. 

Displays are equally difficult. Often the programmer 
is forced to deal with display data at a very low level. In 
order to create his display, it may be necessary for him to 
work at a level of poking bits out the processor port to the 
terminal. By defining data types that include objects which 
represent concepts appropriate to visual display processing, 
the programmer will be freed to work at a higher conceptual 
level . 
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Due to the common nature of this problem, with the 
database we find ourselves in a situation not much simpler 
than the one just described. Since a single database is usually 
designed to fulfill only a very specific task, for instance, 
running the passenger reservation system for an airline, first 
of all the logical structure of the database to be created must 
be developed. This can be done using a data structure diagram 
which contains all the required entities including the relation- 
ship among them. But while this step is achievable without 
consideration of the later implementation, we have to give up 
this kind of abstraction in the second phase when the diagram 
is transformed into a design that conforms to the limitations 
and peculiarities of a given database management system (DBMS). 
The programs themselves which may be created in parallel with 
the development of the logical database structure must apply 
to the standards of the database type chosen, thus putting the 
programmer in a similar situation as for all conventional 
machines . 

We will attempt to minimize the dependence of data upon 
its representation through the use of "abstract data types." 

Our notion of data is very general. It ranges from integers, 
to image and database objects, and to program instructions. 

Data type representation will be hidden and abstract operations 
will be provided in the same way as with traditional abstract 
data types. If these data types can be kept representation 
independent, then portability is aided. 
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3 . 



Intent Expressive Resource Abstraction 



Conventional architectures do not permit us to unam- 
biguously express our intent in a program. Artificial data 
types, combined with typical resource models, force ambiguity 
and the overloading of data structures. Stack frames are a 
good example of this. The semantics of the frame combine those 
of an array and those of a stack. Meanwhile, the whole thing 
is implemented in memory, with the data types overlaid on an 
array of fixed length cells. 

We claim that applying methods similar to those used 
to describe abstract data types, we can describe an abstraction 
of the physical resource of a machine which benefits not only 
from the formalism used to specify it, but also permits the 
implementor to clearly interpret the intent of programs written 
for it. 

C. METHODOLOGY 

The goal of the research done by Yurchak and Hunter, and 
now of this thesis is to contribute something of practical 
significance to the study of software portability by treating 
an area which has been largely ignored, the design of a formal 
abstraction for the computing machine itself. We have innumer- 
able high level programming languages, programming environments, 
graphics languages, database machines (backend processors), 
query languages, file systems, operating system command inter- 
preters, a whole host of different abstractions tailored to the 
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task of providing us with just enough information to do every- 
thing we need to do, and nothing more. So why, then, have we 
failed to develop abstractions for the hardware resources, upon 
which we are so dependent, which are more than just a collection 
of registers, opcodes and some arbitrary rules about how they 
interact. A more difficult but certainly more important task 
than actually defining the abstraction is developing a methodology 
for producing other resource abstractions. 

Our method has been to take a naive approach towards all 
areas of the design and implementation process not directly 
related to the specification itself. We do this for two 
reasons. First, we can take for granted the large body of 
research in programming languages and computer architecture, 
we are designing neither a language nor a processor, even though 
"ad hoc" examples were required to complete the implementation. 
Second, the research is intended to benefit programmers. Since 
it is unreasonable to expect those who may use this method to 
understand the theory behind the specification, the key to 
understanding the reasons for our design decisions lies in the 
way we coded it. Thus, cleverness has been eschewed in favor 
of clarity. 

Our task in this thesis, then, is to examine a wide range 
of issues which impinge on the process of designing and imple- 
menting the specification of a database system, and then to 
describe how we went about actually doing it. 
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II. THEORY 



The formal specification method used to define the Abstract 
Machine (AM) is based on algebraic semantics. This approach 
was chosen because algebras, due to their hierarchical struc- 
ture, enable us to deal with complex problems or to control 
complex situations by decomposing them into simpler subproblems, 
with clearly determined interfaces. 

Clean interfaces, on the other hand, provide a sound basis 
for modifying or combining existing programs, which is our in- 
tention in advancing AM from version 2.0 to version 3.0. But 
algebraic semantics also contribute to solve the portability 
problem for software systems, since they represent a high level 
of abstraction which is the only promising means to narrowing 
the semantic gap. 

Abstraction allows us to deal with concepts apart from 
particular instances of those concepts and to concentrate on 
the essentials only. Abstract data types are the fundamental 
elements a formal specification is built upon. Guttag [Ref. 5] 
states that to describe an abstract data type precisely, its 
specification must comprise both the syntax and the semantics. 

According to Guttag, a formal specification should meet 
the following criteria, which were taken from Hunter [Ref. 3], 
if it is to be useful: 
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it must be restrictive enough to ensure that nothing 
unacceptable to the specifier will meet the require- 
ments imposed by the specification; 

* 

it must be sufficiently general to ensure that few, if 
any, acceptable entries are precluded; 

it must be understandable, so people can work with 
it . 

From [Ref. 2], we note that to achieve true portability, we 
must be able to demonstrate the following properties in our 
implementation : 

the specified semantics actually implemented on the 
source machine are completely unambiguous; 

the implementation on the source machine is "correct." 

Thus, our method of specifying must be formal enough to permit 

proofs of correctness. Exhaustive testing, however, especially 

when dealing with complex specifications, is usually not 

feasible and so the only true statement we can make is that 

our specification is correct at least with regard to those 

tests actually performed. 

Algebraic specifications meet the above criteria for achiev- 
ing true portability. Here we find a significant body of re- 
search already in place in the area of abstract data type 
specification. Goguen [Ref. 6] and Guttag [Ref. 5] treat this 
topic in great detail. We will not so here.- Instead we give 
an overview of the important concepts of abstract data types, 
and direct the reader to the original works for more in-depth 
study of the underlying thoery. Davis [Ref. 7] provides the 
theoretical basis for the resource specification method. 
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Davis [Ref. 1] also provides additional background but with 
an emphasis on practical issues. 

* 

A. ABSTRACT DATA TYPES 

The underlying principle that gives mathematics the power- 
ful tool for generalization is its intention to specify the 
fundamental nature of a system by stating only a few basic 
properties. In order to describe an entire system by means 
of a small number of its characteristics it is necessary to 
find out what exactly these characteristics are and how to state 
them in terms that define all the systems of this particular 
category. This can be achieved effectively by applying the 
technique of data abstraction, which is a synonym for the term 
"abstract data type." 

In general, abstract data types refer to the fact that 
permissible operations on the data ojects are emphasized, 
while details about the representation of the data objects 
are suppressed. Because data abstraction focuses mainly on 
functional properties but ignores unimportant things like 
representation details, only some of the many possible func- 
tional properties have usually to be specified. This allows 
us to define even complex systems by- means of abstract data 
types, or in other words, via certain sets of data values to- 
gether with the corresponding sets of primitive operations on 
those values. 

The properties of abstract data types again are specified 
by algebraic axioms which define all mathematical systems and 
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provide the basis for deriving additional properties that are 
implied by the axioms. This will be discussed in more detail 
later in this chapter. 

The stack, queue, or list serve as typical examples to 
demonstrate how data abstraction works; all of them can be 
characterized by simply defining the essential operations that 
may be performed on each individual system. For example, a 
list could be characterized by operations such as NIL that 
creates an empty list, FIRST that returns the first member of 
the list, PREFIX that adds a new member to the front of the 
list, and NULL that tests for an empty list. Using this ap- 
proach the programmer need not care about how the list and 
its manipulating functions are actually implemented, which 
allows him to concentrate on his programming job. And this 
principle definition of the list can be used for all systems 
of type "list" because the description has been kept very general 
by means of abstraction. 

Besides providing us with a very important mechanism for 
writing well-structured programs, abstract data types make 
program modifications easy. As long as the interfaces of the 
manipulating functions remain unchanged, internal details may 
be modified without affecting other program components in an 
unwanted way. 

Thus, in applying the methodology of data abstraction we 
are forced to clearly specify our intentions, which in many 
situations is the stimulus to think intensively about what a 
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system really is or does, and then to describe the result in 
an unambiguous manner. Due to its clear style and high level ' 
of abstraction, the so-defined system not only is independent 
of its originator, but is also easier to understand. 

B. STRUCTURES 

So far we have discussed how to use the mechanism of abstrac- 
tion in order to handle complex systems but we're primarily 
concerned with the consideration of the permissible operations 
on those systems, like the PREFIX operation for lists. In this 
paragraph we will now examine the more systematic definition of 
structures. Clocksin [Ref. 8] defines a structure as a single 
object that consists of a collection of other objects, called 
components. The components are grouped together to a single 
structure for convenience in handling them. Thus, a structure 
can be characterized by the kind of its components and the way 
they are arranged. Structures are helpful . in organizing data 
since they allow a group of related information to be considered 
as a single object instead of different ones. The decomposition 
of data into individual components depends solely on the pur- 
pose which is to be achieved in solving the particular prob- 
lem; so it is up to the programmer to create the structures that 
contribute most in reaching his intended goal. 

To return to our former example, the list, which is a struc- 
ture itself, what exactly are the kinds of components and their 
allowable arrangements? For the list as an ordered sequence of 
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elements the order of the elements in the sequence matters, or 

as stated in MacLennan [Ref. 9], the allowable arrangements are 

% 

finite linear orderings. The components of a list may be any 
terms, including constants, variables, booleans, and lists 
themselves. Due to these properties lists can represent prac- 
tically any kind of structure that might be convenient for 
symbolic computation. 

So, for example, if one would like to describe a thing on 
the basis of certain attributes corresponding to it, the enumer- 
ation of these attributes could be considered as creating a 
list by which this thing can be defined: 

thing: attribute^, attribute 2 , . . . , attr ibute n 

Bringing the attributes, or components of the list, then into 
a particular oder and specifying the values they may take, enables 
us to create classes of related lists. This can be very useful 
in grouping things of the same type together, as it is the case 
in all database systems: 
class : 

thing.: <attribute, , , attribute, attribute. > 

^1 11 12 In 

thing- : <attribute-. , attribute-- ,..., attribute- > 

^2 21 22 2n 



thing : <attribute ., attribute -,..., attribute > 

^m ml m2 mn 

This simple example will be discussed in much more detail in 
the following chapters. 

In the previous paragraph we have already determined the 
primitive operations performed on lists. There are three 
classes of operations on structures in general: 



25 



constructors which allow us to build a structure in 
accordance with its predefined characteristics (like 
PREFIX for lists) ; 

selectors which allow us to obtain a component from 
the structure (like FIRST) ; 

predicates which allow us to determine the arrangement 
of the components in a given structure and return a 
boolean value (like NIL) . 

Depending on the kind of structure one wishes to describe, 
there is a certain number of operations required; for lists 
it turns out that just six operations (two for each construc- 
tor, selector, and predicate) are sufficient, while, for 
example, the description of a stack would require only five 
operations (NEW and PUSH as constructors, POP and TOP as 
selectors, EMPTY as predicate): 



STACK 


CONSTRUCTORS 


SELECTORS 


PREDICATES 


empty 


NEW 


- 


EMPTY 


nonempty 


PUSH 


POP 


- 






TOP 





But apart from the number of actual operations which is varia- 
ble, the three fundamental classes of operations remain un- 
changed for any structure. And there is one more point that 
should be mentioned: Selectors and constructors invert each 

other in some cases. For example, for the stack we have 

POP (PUSH (stack, X) ) = stack 

which means that pushing an item X onto a stack and immediately 
popping it off again leaves the stack unchanged. The same 
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would be true for 



PUSH (POP (stack) ,Y) = stack 

if the same item Y just popped off the stack was immediately 
pushed back onto the stack again. 

But as fine as the inversion of selectors and constructors 
works for stacks (unrestricted in the case of POP (PUSH)) or 
for lists, it would not work for queues because items are then 
added to the rear end while always removed from the front. 
Keeping these correlations in mind makes it easier to develop 
our algebraic specification later. 

C. ALGEBRAIC SPECIFICATIONS 

Specifications are particular and detailed descriptions of 

things; they contain essential information about the dimensions 

and peculiarities of the described objects. They furthermore 

represent a convenient way to describe the generally infinite 

objects of initial algebras in finite terms if we want to build 

our abstract data types on an algebraic basis. 

Such a specification is also known as "operator signature" 

and consists of two major components: 

the syntax whose purpose is to define the constants and 
operations as well as the axioms as intermediate step 
in developing the semantics. 

the semantics of the data type as part of the realization 
which is mostly of concern for the implementation. 

In mathematical notation a specification can be seen as a 

triple <S,Z,£> where E is a S-sorted signature (this means, it 



27 



is based on the operands of sort S) and £ is a set of Z-equa- 
tions. Here <S,Z,£> specifies an abstract data type by defin- 
ing T„ which represents an isomorphism class of Z-algebras. 

An algebraic specification represents something between our 
intuitive sense of what we want and the actual computer code. 
This characteristic feature facilitates the translation of our 
ideas into working programs and narrows the scope of possible 
interpretation by the application programmer. It also allows 
us to augment an existing data type by introducing so-called 
derived operators without the need for rewriting the initial 
operations, or to extend existing specifications to make their 
data types available to others, thus avoiding unnecessary 
redundancy . 

1 . Syntax Part 

The definition of an abstract data type itself should 
tell us all we need to know for using it effectively. But 
first of all, how can we be sure that we have selected the 
correct level of abstraction to begin with? MacLennan [Ref. 

9] states that there is in fact no formula for calculating 
such a correct level, it rather depends on our individual view 
of the world and our needs at the moment. The chosen approach 
should, however, guarantee that it really models our abstrac- 
tion of the part of the world we want to describe. 

So, in order to start we list the constants and the 
primitive operations on the data types to be defined and, in 
doing so, we create the legal ways in which expressions in- 
volving these data types can be constructed. 
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For each primitive operation it is necessary to explicitly 
state, the 

name of the operation; 
type(s) of its argument (s); 
type of value returned; 

thereby setting the domain of the arguments and value for 
each operation: 

operation: (argumenttype^fargumenttype^j • • • ,argumenttype n ) -*■ value type; 

As an example, the syntax for integer addition could be written 
in the following way: 

add (integer, integer) integer; 

The syntax chart for the general case which is a modification 
of the charts usually found in the ADA programming language is 
shown in Figure II. 1. 



> 


operation — (T') — --> 


argument 


1 

— ! 

8 

1 

1 

0 

1 

1 

V 


value 






~8 







Figure II. 1. Syntax Chart 



In short, the purpose of specifying the syntax of an abstract 
data type is to define 

1) the legal forms of expressions, and 

2) the way in which the constants and operators can be 
combined into expressions. 
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Generally, it seems to be wise to build specifications in a 
bottom-up way, which means starting with the most primitive 
type of data and then proceeding in gradually reaching a higher 
level of abstraction on the basis of the more elementary types 
while hiding the details of the lower levels. 

But in spite of this approach, each data type has to 
be considered independently of its later implementation and 
must be treated at any given level as if it were itself a 
primitive one which, on the other hand, could lead to some 
redundancy . 

2 . Axiom Part 

Having defined the legal (or well-formed) expressions 
and the types of values they return in a rather symbolic way, 
we next consider the meaning of those primitive operations, 
this means, answering the question of what values they in fact 
compute when given legal inputs. This is done in the axiom or 
property part of the specification which therefore can be re- 
garded as a refinement of the preceding syntax definition. 

Semantics, in general, deal with the actual realization 
of our formal terms; here we are, in accordance with our inten- 
tion to use an abstract terminology as far as possible, not yet 
interested in any programming language that could do the job, 
but prefer to give a set of mathematical equations, or axioms, 
which define the meaning of the operations in a way entirely 
independent of the final implementation. This approach of 
applying mathematical techniques eases the reasoning about 
well-formed expressions. 



30 



Trying to mathematically specify the axioms we face 
the - problem of what it is that has to be specified and to 
what extent. As for determining the correct level of abstrac- 
tion to start with, there is no definite solution to this 
problem. Basically, we want a set of equations which defines 
the properties of all well-formed expressions. It is mainly 
up to the creator of the specification to decide what kind of 
meaningful interactions between the operators should be included, 
as long as these equations are complete and define the result 
of a function for all legal inputs. 

For example, the properties for the operation 'integer 
addition/subtraction ' 

+,- : (integer , integer) — > integer; 

could be described as follows: 

a+b = b+a; 
a+(b+c) = (a+b)+c; 
a+0 = a; 
a+(-a) = 0; 
a-b = a+ (-b) ; 

The final step then would be to find the minimum complete set 
of equations, which means listing only those equations abso- 
lutely necessary to define the properties of the primitive 
operations, including implicit statements. But since it is 
sometimes more convenient to directly state equations which, 
thinking strictly mathematically, are already contained in other 
statements, it is legitimate to introduce them as so-called 
derived operators . 



/*commutative*/ 

/*associative*/ 
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An example of such a derived operator is the boolean 
function IMPLIES: 

IMPLIES (X,Y) = OR (NOT X,Y); 

which is equivalent to the combination of two simpler functions 
containing NOT and OR. By this means we can add new operations 
and their defining equations to a data type, whenever it is 
useful within the specification. 

3 . Problems with Algebraic Specifications 

From the preceding paragraphs it should become clear 
that there is no other way in creating a database for the Ab- 
stract Machine except of defining a formal specification first. 
This gives us the tool to concisely describe our intentions in 
an unambiguous and rigorous manner. But it also forces us to 
view the overall problem of what a database actually represents 
in a strictly mathematical way. This means, we first must 
determine the primitive names that form the syntactic realm and 
describe all legal operators. We then must specify the corres- 
ponding universe of discourse, which contains our primitive 
objects, and the functions that map each name from the syntac- 
tic domain to its counterpart in the semantic domain. 

Although this approach often does not harmonize with 
our intuition, since the human mind tends to be more liberal 
than rigorous, it has the distinct advantage of providing us 
with a clear structure which is easier to understand and where 
each defined operation can be proved correct. We consider 
this basic type as the mathematical part of the specification. 
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This method furthermore has the advantage that, given 
the operation presently performed and the current state of the 
machine which corresponds, as Fairley [Ref. 10] states, with 
". . . the information required to summarize the status of 

system entities at any particular point in time, . . . the 

next state can be determined." 

During the research phase for this thesis, however, it 
became obvious that it often is very difficult to translate 
relatively simple models of the real world into terms of alge- 
braic expressions. Besides avoiding unwanted inconsistencies 
the problem centered on the formal requirements for being precise 
and for specifying the fundamental parts of our database, 
wherever possible, by stating only the absolutely indispensible 
basic properties of the system from which all other operations 
can be derived. 

Thus, in the beginning of our work the syntactic speci- 
fication of the stack operations was studied. But due to its 
last-in first-out property which is not very helpful for data- 
base operations, the stack did not provide the paradigm with 
which to continue. As a more suitable example that manifested 
the difficulties in writing an algebraic specification the 
first-in first-out property of queues was then examined. The 
specification shown in Figure II. 2 is built upon an example 
given by Fairley [Ref. 10]. In this example (Figure II. 2), 

CREATE and WRITE are serving as constructors that build up or 
fill the queue. EMPTY and READFRONT describe its behavior. 
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Syntax : 



Operation 

CREATE 

WRITE 

READFRONT 

DELETE 

EMPTY 



Domain 

( ) 

(queue , value) 
(queue) 

(queue) 

(queue) 



Range 

— > queue 
--> queue 
--> value 
— > queue 
— > boolean 



Axioms : 

EMPTY (CREATE) = true 

EMPTY (WRITE (queue , value) ) = false 

READFRONT (CREATE) = error 

DELETE (CREATE) = error , if EMPTY (queue) then C RE ATI 

DELETE (WRITE (queue, value) ) = J else 

) WRITE (DELETE (queue) , value) 

r if EMPTY (queue) then value 
READFRONT (WRITE (queue, value) ) = J else 

( READFRONT (queue) 



Figure II . 2 . A Simple Specification for the Queue 

DELETE acts as a modifier to the queue. While READFRONT -always 
returns a copy of the value sitting in the front position, the 
operation DELETE actually removes this value from the queue, 
thereby changing the state of the system. 

The problem encountered here is that we are not able to 
clearly define all of the axioms but instead are forced to make 
some concessions in accordance with the prevailing state of 
the queue. This is caused by the fact that the value presently 
read from the queue is not necessarily the one entered last 
(compare Figure II. 3). 
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n+i n+2 



n+1 



n 

front 

value 



Figure II. 3. The Queue Principle 



To remain consistent it is therefore necessary to introduce the 
conditional "if-else" statement for a part of the axioms which, 
on the other hand, takes away some of the simplicity. Compared 
with the stack operations where it is sufficient to increase 
or decrease a counting device by a number of 1 with each item 
added to or subtracted from the stack, the queue operations 
require a more sophisticated mechanism to keep track of every 
single item in the queue, if one really wants to be precise. 
This precision could be achieved by indexing the items when 
inserted into the queue. The syntax for these operations is 
easily defined, as shown in in Figure II. 4. 



Syntax : 

Operation 



Domain 



Range 



CREATE 

WRITE 

READFRONT 

DELETE 

EMPTY 



( ) 

(queue , valued 
(queue) 

(queue) 

(queue) 



— > queue 

— > queue 

--> value . 

3 

— > queue 
— > boolean 



Figure II. 4. Syntax Part for an Index Queue 
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But since we have introduced the index values "value^" and 
"value^ , "we now must describe their particular properties in 
the axiom part. This obviously is a complicated method of des- 
cribing the relatively simple arrangement of a queue in terms 
of an algebraic specification, and also proves to be a rather 
difficult effort. But to our knowledge, there is no really 
elegant solution to this problem available at the present time. 

The previously mentioned indexing methodology can only 
be simplified by reducing the queue to its basic operations in 
a similar way as done with the abstract specifications for the 
natural numbers or integers. Here, for example, the number 1 
is expressed by the paraphrase "succnat ( zeronat ( ) )," and each 

succeeding number can be described by adding just another 
"succnat" in front of this fundamental expression. Applying 
this technique to the queue problem allows us to keep track of 
every single value written to the queue and read or deleted 
from it. 



So instead of introducing the extra indexing operation, 
we could integrate the state of the queue ( ' quaddr ' ) and modify 
the specification as demonstrated in Figure II. 5. On the 
basis of these few axioms it becomes possible to describe each 
state of the queue by an appropriate combination of the given 
operations. The following is dn example of this: 



READFRONT (WRITE (WRITE ( INITIALIZE ( ) , vl ) , v2 ) ) = vl ; /*v:value* 
READFRONT (DELETE (WRITE (WRITE (INITIALIZE () ,vl) , v2 ) ) ) = v2; 
READFRONT (DELETE (WRITE (INITIALIZE () ,v) ) ) = undef; 

READFRONT (WRITE (DELETE (WRITE (INITIALIZE () ,vl) ) ,v2) ) = v2 ; 
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Syntax : 



Operation 



Domain 



Rahge 



INITIALIZE (qaddr, state) 
READFRONT (qaddr , state ) 
WRITE (value , qaddr , state) 
DELETE (qaddr , state) 

Axioms : 



— > state 
— > value 
— > state 
— > state 



READFRONT (qaddr , INITIALIZE (qaddr , state) ) = undef; 

READFRONT (qaddr , WRITE (value , qaddr , INITIALIZE (qaddr , state) ) ) 
= value; 



DELETE (qaddr , INITIALIZE (qaddr , state) ) = undef; 

DELETE (qaddr , WRITE (value, qaddr , INITIALIZE ()) ) = INITIALIZE () 

DELETE (qaddr , WRITE (value , qaddr, state) ) = 

WRITE (value , qaddr , DELETE (qaddr , state) ) ; 
if not (INITIALIZE () ) 

then READFRONT (qaddr , WRITE (value , qaddr , state) ) = 

READFRONT (qaddr , state) ; 



end if ; 



Figure II. 5. A Specification for the Queue Including 
the State 



From these examples, where we omitted the arguments "qaddr" and 
"state" in favor of clearness, the importance of placing the 
parentheses into the correct locations becomes obvious. The 
previously defined operations are illustrated in Figure II. 6. 

A value different from the one residing in the front position 
can only be read from the queue after the front value has been 
deleted, so a 

READFRONT (READFRONT (WRITE (INITIALIZE ( ) ,v) ) ) 
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in (WRITE) 



val (n+1 ) 



n;x. 



qu eue 



val (n) 



val (n) 







INITIALIZE 


val ( 2 ) 


val (1) 


state 




val ( 3) 


val ( 2 ) 



out (DELETE) 



READ 



[ =val (1) ] 



DELETE 



[erase val ( 1 ) ] 



change of state 

Figure II. 6. Illustration of Queue Operations 



would return two times the value "v", which is similar to the 
corresponding TOP operation for the stack. Although by this 
method some of the axioms and the " if-then-else " statements 
could be eliminated and furthermore, the requirements for an 
abstract specification can be satisfied, it does not seem to 
be an elegant solution to the queue problem either. The reason 
for integrating this deviation into our research work was to 
give the reader a better understanding of the problems that 
had to be managed in writing a formal specification for a 
database, which is not as simple as the queue. 

4 . Error Handling 

A major aspect in creating a specification is how to 
deal with the situation should the user manipulate the defined 
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operations in a way that would result in an error. Because it 
is part of the human nature to fail once in a while, vital 
systems tend to be equipped with exception handling mechanisms 
which prevent the overall system from breaking down and becoming 
worthless, should a predefined type of error occur. This is 
also known as fault tolerance or lenience, and represents the 
opposite to the more mathematically sound term "strict," where 
a function becomes undefined whenever one or more of its argu- 
ments are undefined. 

Error detection always causes a great deal of problems, 

and once having been successful it is a rather philosophical 

question of how to proceed, as long as a collapse of the entire 

system can be avoided and we get the information that a certain 

error has occurred. In general, every attempt to handle this 

problem should be based on the understanding that 

any operation which encounters an error is computationally 
meaningless ; 

if an operation encounters an error, then any subsequent 
operation which utilizes the erroneous result must also 
return an error; 

errors must not be hidden, but must be known to the user. 
These statements were directly taken from Hunter [Ref. 3], since 
he considerably modified the error handling routines for the 
Abstract Machine (version 2.0), which will be discussed later 
in this section. 

One interesting but mathematically not indisputable 
approach was introduced by Guttag [Ref. 5] with the term 
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"undefined" for equations whose values were not determinable, 
for example, when attempting to read an item from the empty 
stack 

READ (CREATE) = UNDEFINED. 

But since the operation READ can only return a value from the 
stack, we either have to treat UNDEFINED itself as a value or 
READ as an only partially defined function. 

In the meantime, this problem was solved by Davis [Ref. 

1] ; his method has been applied to the AM specification and 
will be described below. 

Another approach that was used by Yurchak [Ref. 2] for 
the initial AM (version 1.0) is to modify the specification and 
include an error message. However, it soon became obvious, that 
in adding such an error message to the specification, care has 
to be taken of all the possible combinations the newly created 
error message could be involved in. This is in accordance with 
the above listed understanding that, if we get an error, any 
operation on it yields an error, too. But it also means that 
the number of additionally needed error axioms quickly leads 
to an extent which is no longer reasonable. 

To get an idea what dimensions we easily reach in order 
to remain consistent, we only have to consider the part of 
the specification for natural numbers that deals with the special 
error axioms: 
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PREDNAT( ZERO NATO ) 

PREDNAT (NATERROR) 

SUCCNAT (NATERROR) 

SUMNAT (N , NATERROR) 

S UMNAT ( NATE RRO R , N ) 

SUMNAT (SUCCNAT (M) , NATERROR) 
S UB NAT ( N , NATE RRO R ) 

SUBNAT (NATERROR, N) 

MLTNAT (NATERROR, X) 



NATERROR 

NATERROR 

NATERROR 

NATERROR 

NATERROR 

NATERROR 

NATERROR 

NATERROR 

NATERROR 



where NATERROR would have to be specified as the extra operator 
class 

ERROR 

OP 

NATERROR: — > NAT. 

Although these error axioms would reduce any term containing an 
error to the error message of the appropriate sort, thus 
eliminating unwanted elements of the carrier of sort NAT in 
the above example, it is obviously not practical to follow this 
approach. We therefore succeed with the concept of "undefined" 
as introduced by Davis [Ref. 1] and described by Hunter (Ref. 

3] , since this method allows us to keep the number of additional 
axioms manageably low. 

The underlying principle is just a different way of 
viewing the mapping of elements from a given domain to their 
images using a certain function. For example, if we let f be 
a function from A to B and let A' be a subset of the domain A, 
then f ( A ' ) denotes a subset of B, the image of A' under f. We 
now consider A' as the domain of our constants and operations 
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defined in the syntax part of the specification. Furthermore, 
we are interested only in the corresponding values they are 
mapped to by the function f (see Figure II. 7), while ignoring 
all the undefined operations in the set A-A' , or in other words, 
the attempt of mapping an element from the undefined set re- 
sults in an undefined value. 

A B 




Figure II. 7. The Problem with Undefined Operations 

"Undefined" has the following properties: 

undef is used to describe the illegal operations; 
if t = undef then A (x^ , , . . . , t , . . . , x n ) = undef; 
where "A" is any operator in the specification, and "x^" is 
an expression; 

any equation containing undef is equivalent to undef; 

in a realization, if undef is encountered, the processing 
halts immediately and an appropriate error message is 
given . 
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So, instead of listing every single possible MATERROR, all we 
have to do is add the axiom 

PREDNAT ( ZERONAT ( ) ) = undef; 

to our specification of the natural numbers, which served only 
as an example for the general case, thereby solving the "prede- 
cessor of zero" problem without the introduction of a special 
error operator. The effect is to restrict the range of free 
variables that apply to an axiom. This becomes clearer if we 
look at the following construction, where we substitute 
ZERONAT ( ) for the free variable n: 

SUCCNAT ( PREDNAT (n) ) = n; 
now replace n by ZERONAT () 

SUCCNAT (PREDNAT ( ZERONAT ( ) )) 

SUCCNAT (undef) = ZERONAT (); 

undef = ZERONAT (); 

The evaluation of this axiom shows that substituting ZERONAT () 
for n leads to an undefined result, which is quite correct, 
but returns the appropriate value for all free variables 
otherwise . 

Thus, PREDNAT (n) does not exactly belong to the set of 
constants and operations defined in A' because for some cases, 
or precisely when n is replaced by ZER0NAT(), the value it maps 
to becomes undefined. We therefore say PREDNAT (n) is only 
partially defined and must be seen, similar to the POP operation 
for stacks as a member of the overlapping set of partially 
defined operations (Figure II. 7). 



/*axiom to start with*/ 
= ZERONAT (); 
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Analogously, we receive a similar result for all those 
specified data types where a faulty user action may turn out 
as something undefined, like trying to read a value from the 
empty stack or queue. And since this method has already been 
applied to the Abstract Machine (AM) by Hgnter, this is one 
more reason to continue with it. 
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Ill . 



DESIGN OF THE INTERFACE 



Data that is stored more or less permanently to be manipu- 
lated by a computer resource represents in some way a simple 
database, where the software which uses or modifies these data 
is known as the database management system (DBMS) . The differ- 
ence that makes a database superior to file processing systems 
which can be considered as predecessors of the database and 
will be widely replaced by this newer technology, is their 
capability to provide via the DBMS more information from a 
given amount of data. The DBMS itself is a complex and usually 
large program that acts as a data librarian. If we follow the 
approach presented by Bjorner [Ref. 11], we can view the DBMS 
as the realization of a certain database model; this then 
allows us to divide the further treatment into the two parts 
abstraction and realization, which correspond to the database 
model and the database management system. 

A. BASIC DESIGN PRINCIPLES 

In this part of our work we are not yet concerned about the 
realization but rather concentrate on the problem of how to 
formulate a useful abstraction of the database resource. As 
seen, the desired state of abstraction can be reached by ex- 
tracting the fundamental properties of the object of concern 
on a level which suits our intentions best. A way to do this 
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is to look briefly at the design methodology described by Booch 
[ref. 12] that works for the general case. 

1 . Definition of the Problem 

To get started and to make the overall framework of a 
database more understandable, models are helpful tools because 
they enable us to express relatively complex things in a simpler 
and more evident way. A tree is often used to represent the 
data structure and the relationship between different members 
of the database. One of the typical requirements for a data- 
base system is to find a certain property among stored objects. 

For example, an object with the properties A,B,.C,D 
could be described by a simple tree (Figure III.l), where the 
object is represented by the root and the properties by the 
leaves of the tree. 



o o 

A B C D 

Figure III.l. Tree Representation of an Object 

In combining different objects we can create^very complicated 
trees (also called a hierarchy) which represent the relation- 
ship in a clear way that otherwise would be difficult to des- 
cribe. Our goal now is to develop a system that checks the 
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leaves of the tree for a given condition which could be con- 
sidered as a step towards the often applied function of search- 
ing for a particular object in a database. 

2 . Informal Strategy 

While still ignoring the question whether such a tree 
will actually be represented as a sequential, linked, or in- 
verted list in order to see if a certain condition is satisfied 
by any of the objects, we can apply the following informal 
strategy : 

Find all stored members that satisfy condition B. 

Figure III. 2 gives an example how this informal strategy may 
be used. Thus, having shown how the informal method works, 
the next step is to find a way of formally expressing this 
strategy . 

3 . Formalization of the Strategy 

First we need to identify the objects and their proper- 
ties. To do this we look one more time at the informal part: 
Find all stored members that satisfy condition B. It is one 
of the advantages of the English language that an object is 
always represented by a noun, while adjectives describe the 
properties of an object. In our simple example this gives us 
right away 'member' as the object and 'condition B' as the 
required property. Next we have to identify the operation 
performed on the object which is not difficult either since 
action is described by verbs. In the discussed example, 'find' 
is the one looked for. Given the objects, properties, and the 
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Figure III. 2. An Informal Strategy to Attack the 

Design Problem 
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operations we may perform on them, we now can describe the 
sequence of single steps necessary to 'Find all stored members 
that satisfy condition B' by the relational diagram shown in 
Figure III . 3 . 

Given this design, we could continue and specify the 
interface of each box presented in Figure III. 3. To complete 
the formalization part this would, indeed, be necessary. But 
we then would also find ourselves right in the middle of the 
implementation which is not what we want at this time. We 
therefore stop here short of coming up with a real formaliza- 
tion. The general idea about the possibilities to start 
abstracting the resource however should be a little more obvious 
by now. 




Figure III. 3. Relational Diagram of the Formalized Strategy 
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B. BASIC DATABASE PRINCIPLES 



Before we can start specifying the database resource we 
need some understanding of the fundamental principles every 
database, in general, is built upon. Although over the recent 
years there were various approaches in this area to make data- 
base work more efficiently, such as the introduction of the 
database machine (also known as 'backend'), or the continuing 
research on the multi-backend database headed by Professor Hsiao 
at the Naval Postgraduate School, we consider our database as 
an integrated part of the abstract machine built by extending 
the present AM. So, in order to formulate a useful abstraction 
we have to keep it simple and therefore, are interested only 
in the conventional, single user type of database. 

A database is in fact nothing more than an elegant combina- 
tion of several file processing systems under the control of 
the DBMS (Figure III. 4). 



reports j 
/ 



reports 

X 



Figure III. 4a. Traditional File Processing Approach 




< > 



application 
program Z 




< > 



application 
program A 
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Figure III. 4b. Database Processing Approach 



For a general view of a database structure we refer to the 
architectural description presented by Deen [Ref. 13] . It 
is always a major question how to define and treat data that 
has to be processed by a machine. In the case of a database 
there are as many as five distinct levels data can be viewed 
from, namely, in a bottom-up fashion, the 
physical level 
storage level 
global level 
local level 
user level 

The meaning of these levels (Figure III. 5) is easier to under- 
stand if we start with the global level which represents the 
center part. This level refers to the overall logical descrip- 
tion of the entire database without considering its storage 
representation. It shows the logical relationship among the 
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Figure III. 5. Architecture of a Database: The Five 

Levels for Viewing Data 



objects of the database and gives the conceptual view of the 
system. 

The local level provides us with a subset of the database 
described at the global level. It was introduced with the 
intention to save the application programmer the inconvenience 
of invoking the whole global scheme while he usually is only 
interested in a few specific data items, since his need is 
local and his view is partial. So a subset is the application 
programmer's view of the database. It is a logical description 
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of the part in which he is interested, and therefore represents 
the external view of the system. 

How the data should be organized for storage in the physi- 
cal device is specified at the storage level which consists of 
entries for overflows, physical block sizes, and data placement 
techniques. Access paths can also be specified here. 

Whereas global and local level are logical descriptions, the 
physical level is the physical database itself. The database 
is stored on physical devices in conformity with the specifica- 
tion of the particular method applied at the storage level, 
where the purpose of this method is to optimize the overall 
performance of the database whose logical description is given 
at the global level. The fifth level is the view of the data- 
base as seen by the end user from a remote terminal using a 
special, high level query language. 

Since the view of data at the user level as well as the 
physical level are not of particular interest for our research, 
we shall exclude it from subsequent discussions, concentrating 
only on the application program, the storage, and the concep- 
tual (global) and external (local) view. The application pro- 
gram is stored permanently and is always available to the user. 
It is usually written once, or maybe a few times, should the 
database description be changed, and can be invoked by special 
commands. To manipulate data in the database by the applica- 
tion program a sublanguage, the so-called query or data manipu- 
lation language (DML) is needed, one for each host language. 
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The DML acts as an interface language with the database which 
enables the application programmer to "navigate” through the 
database with a search strategy defined by the logical rela- 
tionships of his data at the local level. An application 
program containing DML statements has to be compiled either by 
an extended host language compiler or by a special DML proces- 
sor followed by a host language compiler. 

In contrast to a typical compiler however, this device, the 
first of three major software pieces, also known as query 
processor, does not generate machine language but rather a 
sequence of commands that are passed to other parts of the 
database management system. The query processor needs to know 
about the structure of the database, so it can interpret special 
terms in the context of the particular system. This information 
about the database may already be built into the query processor 
itself. 

The output of the query processor is fed into the database 
manager (Figure III. 6), where it is translated into terms the 
third software component in our simplified database blockdiagram, 
the file manager, can understand, which means, into operations 
on files rather than on the more abstract data structures of 
the database description (global level). The file manager may 
be the general purpose file system provided by the underlying 
operating system (OS), or it may be a specialized file system 
that knows about the particular way in which the data is stored 
in the database. 
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Figure III. 6. Simplified Block Diagram of a 

Database System 



The overall software that permits the use or modification 
of the data stored is a DBMS which basically covers all the 
software components we are mostly interested in. So this is 
the point in the system where the abstract database resource 
comes in. 
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C. THE ABSTRACT DATABASE RESOURCE 

The AM database resource replaces two of the items shown 
in Figure III. 6, namely the. database manager and the file 
manager. Figure III. 7a shows the block diagram for a database 
system using AM, while Figure III. 7b presents a general view 
of the AM arrangement within the database system operation. 




DBMS Interface 



AM Interface 



Hardware 

Interface 



Figure III. 7a. Block Diagram of Database on 

AM Resource 
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Figure III. 7b. Conventional Database System Operation 

(Compare Hsiao [Ref. 14]) 

So AM takes over right at the boundary where the system changes 
from working on a more abstract basis to an operation depending 
on the particular machine applied. Since AM does not include 
the query processor, it can not be considered as a complete 
replacement of the DBMS but instead covers only about two- 
thirds of the functions carried out by the DBMS before (Figure 
III. 7b). We further recognize that we did not mention another 
specialized language, the data definition language (DDL), 
which in conventional systems serves as the tool to describe 
the entire database once the conceptual scheme is specified. 
However, to keep it as simple and clear as possible we do not 
want to introduce one more high level language, and therefore 
prefer to let this job be done by a special application pro- 
gram, using the query processor as mediator. Since installing 
the database is a one time matter this restriction seems feasible. 
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AM's database primitives are more low level and cover less 

2 

aspects than, for example, the CODASYL model. But they con- 
tain all the fundamental features for creating the database, 
for updating a given value, for inserting new elements into 
the database, and for retrieving special data. These operations 
are considered appropriate for this abstract level, and will be 
discussed in a later chapter. 

In a similar way as for the conventional model, the database 
manager as the AM interface, which in fact is just a collection 
of routines, receives as its input the processed query primi- 
tives in a still machine independent form. This, however, is 
the only kind of input the database manager accepts because, 
since the former DDL entries are now handled by a special 
application program, there is no need for the manager to have 
a second input line. It further should be noticed that the 
security aspect, which means permitting access to certain infor- 
mation stored in the database to authorized persons only, as a 
task frequently carried out by the manager, has not been taken 
into account. This step can be justified with the definition 
of our database as a single user system. Thus, the general idea 
is to model the database resource 'on top' of the existing AM 
(version 2.0) by abandoning all of the usually required high 
level languages like DML and DDL, in order to level the re- 
sources with the AM operations, which is the major step for 
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eliminating the semantic gap. But in contrast to the display 
resource defined by Hunter, AM is not entirely able to oper- 
ate on the machine independent parts created by a conventional 
database system, as long as a separate DDL input is involved. 

When dealing with the physical resource the question to be 
asked first is what purpose it is supposed to fulfill. From 
the programmer's point of view the database should enable him 
to : 

create objects, characterized by particular properties; 

connect the objects in a logical way to a file; 

store the objects without consideration of the physical 
storage method; 

operate on any of the stored objects in an uncomplicated 
manner . 

In addition to the standard file system where the basic 
operations 'open', 'close', 'read', and 'write' will do, a 
database must also permit operations for retrieving a distinct 
object from the storage, modifying it or checking if a particu- 
lar object is stored at all. The details will be described in 
the next chapter, but in general, the database represents the 
state of all the data stored as files and can be considered as 
'just another' resource for AM. 

As mentioned before, the programmer has to start his work 
with the creation of the logical concept tailored for the very 
special kind of database he intends to build. By this logical 
design, or model, he copies that certain portion of the real 
world which describes his view of selected activities best. 
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But as with every model, its capacity is limited, not all 
aspects can be covered. Thus, a careful selection of those 
portions which allow the required logical operations is neces- 
sary. The tool for compressing the parts of the real world in 
such a way that they can be stored within the database is the 
technique of Aggregation by forming a concept via abstracting 
a relationship between other concepts, called components, and 
Generalization by forming a concept via abstracting a class of 
other concepts, called categories. These techniques will be 
discussed in the next chapter. 

Due to the compression however, some questions now become 
unanswerable. It is the task of the database designer to make 
sure that those questions which can no longer be answered are 
of the kind that never will be asked. 

The standard primitives in the real world are the objects 
and certain properties, where objects as already stated, can 
be represented by nouns while properties can be considered 
as adjectives that characterize the objects. We will stick to 
this notation concerning the primitives throughout this paper 
because their meaning is more evident and they represent the 
most abstract level. This is one of the major differences to 
a conventional database where widely a different terminology 
is used. The reason for this is that in a database we actually 
can not work with the real world primitives since a model is 
not the real world itself. But instead we are working with 
representations of these primitives. So whenver a transaction 



60 



from the real world into the conceptual world takes place, the 
notation is changed to indicate this step. In a conventional 
design the objects are represented by the so-called entities . 
which are, in contrast to their physical implementation, still 
unrestricted by the constraints of the computer. Properties, 
in a similar way, are represented by so-called attributes which 
serve as a description for the entities and, while properties 
are characteristics of an object, attributes are representations 
of those characteristics. Thus, attributes are the character- 
istics of the data types (objects) themselves and, in fact, 
every entity has certain named attributes. 

But as stated above, we do not follow this terminological 
excursion for the sake of staying as abstract and representa- 
tion independent as possible. The intention finally, is to 
keep the structure simple, with emphasis on the permissible 
operations and to prevent the programmer from leaving the 
path of unambiguity. 

In AM, database objects are abstract data types. Concep- 
tually, database operation is accomplished in the following 
way. Objects are initially brought in from the disk and stored 
in main memory. To manipulate an object, it is first fetched 
from its memory location. It is then used as an operand in 
some database operation, and the resultant object is stored 
back into memory. At any instance, the memory may contain 
several objects, but the terminal is directed to view only 
some selected object (s) in accordance with the operation just 
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being performed. When these operations finally are completed, 
the objects temporarily residing in main memory are shifted 
back onto the disk under control of the operating system, 
which is not to be discussed here. 
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IV. SPECIFICATION METHODOLOGY 



Because our database is considered as an extension of the 
existing AM we continue the work originated by Yurchak [Ref. 

2 ] using essentially the same specification language which will 
be described later in this chapter. However, before we proceed 
with this, first some understanding is required about the ap- 
proach we took in adding the database to AM. The purpose of 
the next section is therefore to make the reader familiar with 
the special methodology applied in order to design this resource, 
and the chronological steps that were done until finally the 
specification could be developed. 

A. THE FUNDAMENTAL STRUCTURES 

To define the operations that legally can be performed on 
the abstract data types for our database we need some tools to 
describe our intentions and also to preserve the necessary level 
of abstraction. Since the complexity of a database is not 
easily understood, a data model usually is formed as the simpli- 
fied representation of a particular aspect of reality. In doing 
so, the questions that arise next are: what are the elements 

our model will be based on, what actually is it that we would 
like to represent in a database, or what are the specific as- 
pects of the real world we are mostly interested in? Without 
claiming to be absolutely correct in the philosophical view of 
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things, the point to begin with is the fundamental structure, 
known as the primitives in the real world. 

The first phenomenon here is the object, which may be a 
thing, a person, an event, an instruction or, in general, some- 
thing solid that can be seen or touched. When objects can be 
put together under a common but more generalized notation, 
they may form an object class. But it must be mentioned that 
grouping distinct objects together is only achievable by ignor- 
ing their differences at the price of losing some specific 
information as a concession to the generalization. 

The characteristic qualities owned by an object are its 
properties. For the above given examples, it might be the size 
of a thing, the name of a person, the date of an event, or the 
statement contained in an instruction. All the possible 
instances of a property again can be grouped together into a 
set defining the domain of all the values this property legally 
may take, which therefore will be called 'valueset' in our 
specification. This domain represents not just a collection of 
numbers or characters but instead has to be considered as the 
set of all values a given property can have. For example, for 
the object ’person' with the property 'name' the corresponding 
valueset would be the collection of all the names that might 
be found among people on earth. 

An example of how objects and properties are related to 
each other is given in Figure IV. 1, which is based on concept 
developed by Kroenke [Ref. 15:p. 207]. 
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Figure IV. 1. Example of an Instance Value as the 
Intersection Between an Object and 
a Valueset 

Following this approach we can view the abstract model as con- 
sisting of objects and selected properties related to them, 
where each single property is composed of a certain name and a 
specific value from the predefined domain. Although one 
property may take different values, at any instance it can be 
considered as a pair containing a single name and a single 
value. This will be discussed in more detail in Section B of 
this chapter. So in short, we can write as follows: 
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object^ (pair^,pair 2 , . . . ,pair n ) . 

The basic operations performed on our simple database are: 

# 

create 

insert 

modify 

retrieve 

test for membership 

where briefly described: 

create--installs a new database; 

insert--adds a new object to the database; 

modify — changes a certain object by altering one of its 
properties ; 

retrieve--retrieves an object identified by its particular 
properties from the database; 

test for membership--returns a boolean value depending on 
the fact that a particular object does or does not 
belong to the database. 

For futher information the reader is directed to the specifica- 
tion part of this thesis where the entire operations are defined 
in much more detail. 

As already indicated in the previous chapter, we adopt the 
following view: whenever talking about objects and their 

properties we actually deal with primitives of the real world 
which are neither easy to handle nor can they be stored in a 
machine. To be more precise, in constructing a model we only 
work with a representation of the objects and properties but 
not with the primitives themselves. In doing so, the portion 
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of the real world our model tries to catch becomes manageable. 
For example, although we can not put the object STUDENT into 
a database, it is no problem to store the characterstring 
'STUDENT' as a conceptual representation of this object. The 
same is true for properties. Since there is no way to store, 
for example, 15 YEARS, we instead extract the essential infor- 
mation ('15' in this case) which is more convenient. 

Furthermore, there are some restrictions to be taken into 
consideration. For instance, the programmer should not be 
allowed to insert data that does not belong to the valueset of 
the specified property, nor modify a non present value. Such 
cases have to be covered by a special error handling routine. 

B. DEFINING OBJECTS AND THEIR PROPERTIES 

One approach to defining an object in terms of mathematical 
notation can be found in Hsiao [Ref. 14 :p. 67]. Although Hsiao 
uses a different terminology, the proposed concept is as 
simple as it is clear: 

Let A be a set of 'attributes' and V be a set of 'values. ' 

Then a 'record' R is a subset of the Cartesian product 
A x v in which each attribute has one and only one value. 

R can therefore be considered as a set of ordered pairs, 
or in short notation, 

R = [ (attribute , value) ,,..., (attribute , value) ] . 

1 n 

The meaning of this equation is evident, however it does not 
necessarily ensure that a certain value will only be attached 
to an attribute for which it is explicitly defined in the 
corresponding domain. Thus, because our methodology is supposed 
to be strictly formal, the given equation can not simply be 
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translated by just changing terms. But we can adopt the basic 
idea . 

The technique we apply must prevent us from mistakenly 
combining terms that are not defined for each other, and the 
way we described our properties supports this. Since a property 
is composed of a pair containing its name and the appropriate 
set of values which specifies all the legal values for this 
particular property, only combinations between members of this 
pair are possible. At each instance such a property identified 
by a certain name, may take any single value from the corres- 
ponding domain, thus representing one specific 'snapshot’ 
lying within the range of feasible combinations. The following 
example illustrates our intentions. 
property 1 : 

name: 'age' 

set of values (domain) : ' 10 ' , ' 11 ' , ' 12 ' , ' 13 ' , ' 14 ' , 

' 15' . 

property 2 : 

name: 'city' 

set of values (domain): 'Monterey', 'San Diego', 

'Los Angeles', 'San Jose'. 

Legal combinations representing different instances of the 
given properties would be: 

'age' , 'll' 

'age' , ' 14 ’ 

'city' , 'Monterey' 

'city', 'San Diego' 
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however, combinations like: 

'age', 'Los Angeles' 
or ' city ' , 1 11 ' 
are not possible. 

Thus, we have to attack the problem in two successive steps. 
We start with a particular property name ISL out of the set of 
all specified names N and with as the corresponding value- 
set out of the set of given valuesets V. We then can define 
a property in a similar way as described above as the Cartesian 
product x where i>=l. 

This ensures that a property won't have other values than 
those explicitly stated in its domain, where at any instance 
each property name has one and only one corresponding value. 
Having generally defined the property P = X V^, i>=l, we 
now can easily describe an object. as a sequence of one or more 
property instances P' 

0 = < p ’i P V- 

Properties by themselves do not make much sense in a database, 
since it is the object we are interested in. But on the other 
hand, objects are made out of distinct property instances, and 
so both the object and its describing property instances repre- 
sent the primitives in our database. Following a top-down or 
'from the simple towards the more complex' strategy in 
developing a specification for the abstract database, the 
procedure of creating an object is illustrated in the next 
example . 
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An instance of an object 0^ can then be described by a sequence 
of properties P ’ which themselves contain a name and a particu- 
lar value, or in other words, it represents several 'snapshots' 
of the properties P. The previously given description of an 
object should be clear by now: 



A property name will be mapped together with any of the values 
assigned to the domain of the corresponding property, but will 
be restricted to only one value at a time when defining a 
certain object, although a single property name can take differ- 
ent values for different objects. 
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This probably becomes more obvious when looking at a 
graphical example, following in some sense the approach to a 
formal development for data structured in accordance with the 
different database models given by Hull [Ref. 16:pp. 518-528]. 

Notation: Let N be the distinguished set of property names 

and let V be a set of valuesets such that N n V = 0 (no common 
elements) . 

Definition: Then P is the set of all properties, where F 

maps to each subset of P a property name IF and a valueset 
such that the following conditions apply (Figure IV. 2) : 



N (set of property names) 
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F(N i ,V i ) — >P i ; 
g: P.— >V j? 

h: Pj — >Nj ; 

F(g(P i ) ,h(P i ) ) 



P i ; 



Restricting these mappings in such a way that values of a cer- 
tain property can only be transferred from the valueset (domain) 
which is defined for this property type, properties consisting 
of different name/value pairs can be created. 

Applying d = <P,F> then gives us the tool to describe the 
first part of the primitives, the properties. Next we need to 
define the remaining part, the objects. To achieve this, let 
0 be a set of objects, where I maps certain pairs (N^, & P^, 
for l<=i,x, to elements of 0 such that I(N^, ) ^ I (N^ , ) for 

every two N^,Nj belonging to the same object. Then s = <<P,F>,I^ 
= <d,I> can be used to describe any object 0 v by applying I 
one or more times to different 6 P^ . The following 

conditions are true for this mapping (Figure IV. 3) : 

- V>.p;...p u = nvv 1 ] »....“<vv uk ))il 

I<1(0 V )1 - 0 V ; 

The restrictions added are indeed necessary in order to pre- 
vent illegal operations on the sets, which otherwise would be 
possible. Both methods discussed above lead to the same re- 
sult, and it was the goal of this section to give the reader 
an understanding of our strategy in defining objects and their 
properties. Although this strategy may appear somewhat 
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0 (set of objects) 



P (set of properties) 




Figure IV. 3. Creation of Objects 

complex, it represents a serious attempt to handle the data- 
base primitives in a consistent way while staying as formal as 
possible. And before continuing with the next section which 
deals with the creation of object classes, a final note has to 
be attached: To distinguish between different objects it is 

necessary to include at least one name/value pair that uniquely 
identifies each object. This identifier is called the 'key.' 

If there is no such key available then there might be the case 
where it is impossible to distinguish one object from another. 

Objects that are structured in a similar way, which means 
they are defined by the same property names appearing in the 
same order, can be grouped together to form a class. Such a 
class may then be identified by the kind of its property names 
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and the order they are arranged in. However, this is a tedi- 
ous method. It is therefore more realistic to introduce a 
classname as identifier to distinguish between different classes. 

In either case, the kind of identifier is considered to be 
an implementation issue and will be ignored at this point. 

C. OBJECTCLASSES 

A convenient way to handle a large number of objects is by 
grouping them together. This can be done with all objects that 
are related to each other in a logical sense. These sorted 
objects then form a class or subclass of objects, where each 
class has its own characteristics that distinguish it from 
another. Since objects are composed of several name/value 
pairs, the presence of those pairs and the order in which they 
appear is the criterion for associating any given object with 
a particular class. A graphical example of a subclass is pre- 
sented in Figure IV. 4. The subclass can be considered as a 
two-dimensional scheme with the objects arranged in horizontal 
order and the properties as different columns. From this repre- 
sentation it becomes obvious that, if a certain property is 
not contained in the subclass, none of the objects of that sub- 
class can have this property at any instance. In mathematical 
notation this could be expressed as: 

(object ^subclass )y\(pair ^object )-->(pair ^subclass ) 
x y z x z y 

where pair represents an instance of property containing 

name z and one single value from the corresponding domain 

defined for property . 
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Figure IV. 4. Objects Forming a Subclass 

In the same way that objects can be grouped together to form a 
subclass, several subclasses again can be arranged to form an 
objectclass. Both are achieved by means of ' generalization , 1 
a technique discussed in the next section. 

An objectclass can be considered as a three-dimensional 
scheme consisting of 'layers' of subclasses as shown in Figure 
IV. 4. To create this figure, turn the subclass in such a way 
that it fits into the horizontal plane, and then install each 
on top of the others. Using this method, the arrangement be- 
comes more evident (Figure IV. 5). So a subclass equals a cer- 
tain level of this block whose shape depends on the number of 
properties, objects, and subclasses being applied. The entirety 
of all levels or subclasses forms the objectclass. Objects 
which do not belong to one subclass but have to be present 
because they are contained in another, are considered as just 
being left blank in all the subclasses in which they are not 
represented . 



property ± property^ 




Figure IV. 5. Subclasses Forming an Objectclass 

If a certain property is not containted in the objectclass, 
none of the objects belonging to that class can have this 
property at any instance. In mathematical notation this can 
be expressed as: 

(pair sobject )n(object . subclass )/*>( subclass eobjectclass ) 
z x x y y n 

> (pair^eobjectclass^) 

v/here, again pair represents an instance of property con- 

z z 

taining name z and a single value from the corresponding domain 
of property z . So in searching for a particular name/value 
pair, first the objectclass can be checked for the matching 
property name, then if positive, the subclasses have to be 
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checked, and finally the object that responds to the require- 
ments will be localized. By this means a search can be limited 
to those objects most likely to contain the requested name/ 
value pair. 

1 . Generalization 

Generalization is defined as " . . .an abstraction 

which enables a class of individual objects to be thought of 
generically as a single named object" [Ref. 17 :p. 107]. Re- 
placing the term 'named object' by the new term 'subclass' this 
technique provides a way for conveniently describing how sub- 
classes and ob j ectclasses can be constructed. This is true 
because, on the next higher level, subclasses themselves by 
abstraction build a generalized new 'object,' too, the object- 
class (Figure IV. 6a). 




(ob j ectclass ) 



( subclasses ) 



(objects) 



Figure IV. 6a. An Example of Generalization 

By generalization, which can be considered as a bottom-up 
technique, it is possible to create the abstraction necessary 
for the abstract database (Figure IV. 6b). 
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Figure IV. 6b. Creating a Class from Objects by Generalizatioi 



This bottom-up approach, if all the objects belonging to one 
class are included, must then logically be reversible in such 
a way that a given class would lead to every single object being 
defined by that class. For example, the class 'mammals' 
naturally contains also the object 'horse,' and horses belong 
to the class of mammals. 

2 . Aggregation 

In order to define the instance properties of an 
object, those properties must be determined for every object. 
This can be achieved by the technique of 'aggregation' by which 
different name/value pairs are grouped together so that they 
can be used to describe an object (Figure IV. 7). 




Figure IV. 7. Creating an Object from 'pairs' by Aggregation 
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Although this method looks like a refinement of the object, 
aggregation in fact works the opposite way (bottom-up) and 

t 

cannot be treated as an inversion of the generalization. 
Furthermore, aggregation is not automatically reversible, 
which means an object may have certain name/value pairs, how- 
ever these pairs do not necessarily define this specific ob- 
ject in an unique way. For example, although a person can be 
described by the name/value pair ( ' age ' , ' 10 ' ) , this particular 
pair need not necessarily refer to a person. So in contrast 
to the generalization, where an exhaustive installation of 
objects belonging to one class would guarantee reversibility, 
with aggregation this depends on the way an object is viewed. 

Using the method of generalization and aggregation we are 
able to draw a picture of the general structure of the data- 
base (Figure IV. 8). This drawing also clearly demonstrates 
that each instance property of any object belonging to a cer- 
tain class, must itself belong to that class: 

[ ( (name/value pair) t object) ; subclass] t object class 

D. THE SPECIFICATION LANGUAGE 
1 . Grammar 

First developed by Yurchak (Ref. 2] and in a few parts 
modified by Hunter [Ref. 3] , the grammar used for the specifi- 
cation language will be left unchanged to preserve the meaning 
of AM as the machine as originally designed. The grammar for 
the specification language as found in Appendix A is exactly 
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Figure IV. 8. General Structure of the Database 



the same as used by Hunter. The following description of the 
grammar and, in the next section, the preprocessor, represents 
an extract of Hunter's respectively Yurchak ' s work. It was 
inserted to give the reader some understanding of the under- 
lying fundamentals. 

The selected grammar is similar to examples found in the 
literature, but the specification language includes some features 
usually reserved to programming languages. A specification 
with modules called 'spec' is constructed first using this 
language while by means of the 'extension' operator it is 
possible to combine the specs in a hierarchical order. Each 
spec may introduce zero or more new 'sorts,' 'operators' and/ 
or 'axioms.' A 'sort' can be considered as a data type and 
forms an object set from which the operands are selected for 
the operators. The elements in a sort are created from the 
listed 'operations.' Whenever feasible, one or more constants 
are declared in the beginning to provide a basis for other 
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elements. For example, the constant zeronatO would be such a 
basis for generating other elements in spec natural. 

Sorts introduced in a spec may also be added to an 
existing spec through 'extension' of the spec(s) that will be 
taken as the basis, or they may form the primitives for a new 
'branch' of the hierarchy. Extension provides the only means 
of relating the sorts and operators from different specs so 
that the newly declarated operators refer to both the new sort 
as well as to any sort from the extension. 

Parameterized specifications are permitted but their 
use is minimized, as their properties are not well understood. 
Spec string is one representative of this type of specification. 

The semantics and the overall structure of the specifi- 
cation must obey certain rules. All symbols must be unique. 

No symbol may be used unless it has first appeared as the name 
of a spec, in a sort definition, or to the left of a colon in 
an operator declaration. Following this rule guarantees that 
at no time the properties of the object inferred by the name 
are ambiguous. Thus, the structure of the specification is 
much like a Pascal program, but more restrictive. In short, 
there are no self referential specs, and no use of a spec is 
possible before it has been defined. 

The specification language classifies all operators 
into one of three categories: 'primitive,' 'derived,' and 

'hidden. ' 

'Primitive' operators are those which must be imple- 
mented to provide a full instantiation of the spec 
and form the basis of the resource description. 
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Although not every primitive operation needs to be 
directly implemented, the full functionality of each 
primitive operator must be present. It is up to the 
implementor whether he likes to exclude some of 
the primitives or some of the operators described 
by those primitives, as long as full functionality 
remains available from either set of operators. 

' Derived ' operators are those which can be derived 
from the primitives. The implementor may ignore 
these operations because their function always can 
be performed by the composition of primitives. Their 
inclusion is merely a matter of convenience. An 
example would be the derived operators 'or' and 
'implies' in the spec boolean, whose functions are 
entirely covered by the primitive operators 'not' 
and ' and . ' 

'Hidden' operators are those to which the programmer 
has no access. They represent abstractions of the 
machine required to express a certain semantics. It 
might be convenient to have them in one case, while 
in another they may be essential to the semantic 
description. A typical example for a hidden operator 
is the READFRONT operation in the specification of a 
queue, as discussed in Chapter II. Here, this 
operator is required to build meaningful axioms. 

The 'if-then' and ' if-then-else ' constructs are used to build 
conditional axioms. Their function follows the same princi- 
ples as it does in other languages, for instance, in Pascal. 
This means, when the evaluated 'boolean expression' is true, 
the 'then' part of the statement applies, otherwise the 'else' 
part. The 'boolean expression,' finally is defined as 



expression meta_relop expression 



where the term 'meta_relop' stands for the metalanguage sym- 
bols "=" (equality relation) or "!=" (inequality relation), 
and is used to decide about the truth of the given boolean 
expression . 



82 



So in some sense, the underlying grammar for our speci- 



fication language is similar to the ones used for compiler 
compilers. In general, the application of a metalanguage 
provides an important tool to formulate various aspects of the 
developing design, since it can be used as a description for 
another language. Simple technical terms, such as 'if,' 'then, 1 
'else' or 'endif' were introduced to make our intentions more 
clear in both the grammar and specification. In order to dis- 
tinguish between the metalanguage terminology and the regular 
language, metanames always are boldface. A typical represen- 
tative for such a metalanguage is the BNF (Backus-Naur Form) 
which serves as a notation for describing the syntax of pro- 
gramming languages using ordinary technical English, supplemented 
by conventional mathematics. 

2 . The Macro Preprocessor 

The main purpose of the macro preprocessor is to con- 
dense the amount of language wherever repetitions would swell 
the volume of specifications. This technique also improves 
readability because those parts of a specification sharing a 
common macro definition, can easily be identified. And since 
it is based on the same principle, understanding one macro 
definition is the starting point for understanding all of them. 

As with the grammar, the idea of the preprocessor was 
originally introduced by Yurchak when he designed AM (version 
1.0). This convenient technique has been continued by Hunter 
in developing AM (version 2.0), and it will also be used for 
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the abstract database. The fundamental theory remains un- 
changed. In the following section a description of the pre- 
processor is given as it was defined by Yurchak [Ref. 2] and 
adopted by Hunter [Ref. 3]. 

The basic form of a macro definition is 

replace "text . . . " with "other text . . . " 

Since the grammar of our specification language does not re- 
quire quotes, they are used as delimiters for definition and 
equivalence strings. A macro with arguments appears like 

replace (A,B,...,Z) "text . . ." with "other text . . 

where the formal parameters must be capital letters. An upper 
case letter always denotes a formal parameter to a macro, 
since there are no uppercase letters allowed within the spec 
itself. Thus, for the definition 

replace (S) 

"typeof (S) ; " 

with 

"types : -->type ; 
atomofS: val-->S; 
valofS: S — >val; 

then the string 

typeof (bool ) ; 

would be replaced by 

typebool : --> type ; 
atomofbool: val-->bool; 
valofbool : bool-->val ; 
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wherever it appeared. The utility of the macro becomes obvious 
when we look, for example, at the fetch and store operators, 
used to retrieve and store values of any type from/in primary 
memory. All AM data types map into a common sort called ' val , ' 
which is returned from or passed to memory by these operators. 
In order to avoid the need for describing big numbers of vir- 
tually identical mapping functions, by means of macro defini- 
tions it is possible to describe the first data type and then 
just list all the others. This feature clearly simplifies the 
specification task. 

Macro definitions are also excellent for expressing 
certain properties of operators such as commutativity, trans- 
itivity, etc., which are used throughout a specification. 
Instead of writing out the associated axioms repeatedly, which 
could prove to be tedious the definition of macros with appro- 
priate parameters permits a more readable and explicit expres- 
sion of these properties. The following example gives an 
illustration : 

equint: int , int — >bool; 

If the arguments are equivalent, then the operation should re- 
turn true ( ) , otherwise false (). In order to express eqint 
as the equivalence relation on objects of type int, three 
axioms are needed: 

equint (i,i) = true ( ) ; 

equint (i,j) = equint (j,i); 

implies ( and ( equint ( i , j ) , equint ( j , k) ) , equint ( i , k) ) 

= true ( ) ; 
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This by itself would be no reason for concern, but there can 
be a variety of relations like this within a specification, 
and for each single case these three axioms have to be re-* 
peated in some way. Macros provide the adequate solution, 
since a macro defined like 

replace (X, S) 

"equivrel (X , S) ; " 

with 

"for i in S 
X (i , i) = true ( ) ; 
for i,j in S 
X ( i , j ) = X ( j , i ) ; 
for i , j , k in S 

implies (and (X ( i , j ), X ( j , k) ), X (i , k) ) = true ( ) ; " 

enables us to use this definition as a template in which equint 
just has to be inserted 

equivrel (equint , int) ; 

thereby transforming equint into an equivalence relation on 
int in one step. Note that we are not required to explicitly 
specify the type of free variables, since this can normally 
be determined by context. We do so in the interest of clarity 
because there can be no doubt for which type 'equint' is an 
equivalence relation. 
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V. THE DESIGN 



Having an operating AM processor available that already 
includes the control and primitive data type operations as 
well as the visual display device, the next step towards the 
goal of developing a fully operational machine was to add a 
database resource which could do a far better job than a 
conventional file handling system. With the design of the 
abstract database, now a model had to be created that was 
appropriate for manipulating data in a way to effectively sup- 
port the programmer's requirements. Because a database is a 
complicated and complex subject, our intentions were to model 
a resource which includes only the fundamental operations as 
stated in the earlier chapters. This restriction had to be 
introduced in order to keep the time constraints given for this 
thesis. The complete specification for AM is presented in 
Appendix B. 

However, one note of caution has to be added like the one 
originated by Hunter [Ref. 3] in his description of the bit- 
mapped display system: despite our best efforts to be thorough 

and rigorous, this AM specification may still contain some 
errors. This is not only so because extending a program written 
by others most likely supports this possibility, but first of 
all because it is a rather difficult matter to ensure that there 
is no ambiguity in the axioms. It also can not be guaranteed 
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that every portion of the spec is complete so that legal but 

undesirable implementations would not be permitted. 

% 

A. THE DATABASE CONCEPT 

In contrast to the graphics part of AM, the database once 
installed by the application programmer is fairly limited to 
manipulating data in the predefined way. Creativity in the 
sense of trying and improving is only possible during the con- 
ceptual phase which always preceeds the actual installation. 
This means the programmer must have a clear concept about what 
to describe and how to arrange it in the most suitable way 
before the implementation finally can take place. A database 
represents a number of data being arranged in accordance with 
certain characteristics or particular relations of interest to 
the programmer. The main question to be answered is how to 
abstract a database -to its fundamentals so that a programmer 
can work with it. Once the basic elements were identified as 
'objects' and the 'properties' defining them, the next step 
was to develop the set of functions controlling the database 
that would support a natural way of thinking about the intended 
operations. In order to remain consistent, even the 'property' 
as the basic component of an object had further to be split 
into the sub parts ' property_id ' and 'valueset.' 

This approach is certainly different from other methodolo- 
gies because it required eleven separate specifications just 
to formally define the database and its abstract elements. 
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Each specification must be considered as a mandatory step on 
which succeeding specs are built. And each spec contributes 
in an important way to defining the abstract database resource 
and therefore can not be omitted. This number of specifications 
naturally caused some problems when translating every single 
function, in many cases required only for mathematical reasons 
of rigor and without practical usefulness for the programmer, 
into logical sets of operations. Although these operations had 
to be built in and are now available, it is anticipated that 
the application programmer will rather restrict himself to the 
more useful operations typical for database manipulations. 

From the programmer's point of view, it is not of interest 
to retrieve all the values defined for a certain property once 
the domain has been fixed. He more likely wants to determine 
the name/value pairs associated with a particular object or 
find out whether one or more objects meet a given condition. 

Due to the underlying method objects are structured this can 
be achieved on the basis of list functions that will be dis- 
cussed in some detail in the following sections. In general, 
we adopt the idea that a database can be considered as a big 
list. This approach was finally chosen because it facilitates 
our effort to describe the principles of the abstract database. 

A standard database has to be created first in the mind of * 
a programmer, then drawn on a piece of paper and, eventually, 
installed on the computer. This sequence represents a typical 
top-down approach, starting with the overall database, 
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partitioning it into different classes and subclasses and, 
finally, assigning objects to them. This approach keeps the 
programmer at a very low level of abstraction, where the com- 
puter can not provide much assistance. Adding, for example, 
a new object would require us to first specify the particular 
class to which it belongs. It would definitely ease the pro- 
grammer's effort when he could work on a higher level of 
abstraction by using the power of the computing resource to 
insert such an additional object without caring about the 
specific class it refers to. But although this approach has 
some fascinating aspects it was not developed since object- 
classes are characterized by the kind of their property names, 
and thus have to be specified carefully. The probability of 
erroneous entries seemed too high to adopt this concept for 
our research. 

As stated in Chapter III, we also abandon the introduction 
of a data definition language (DDL) and a query language since, 
due to their high level, a great deal of the intended abstrac- 
tion would be taken away. This becomes quite obvious just by 
the fact that there are meanwhile several, non-compatible 
query languages established. Because our goal is to specify 
one particular part of a database, namely the interface be- 
tween the conceptual level and the physical level, we confine 
our work to the fundamental principles and focus exclusively 
on the essential aspects of the database. For the interested 
reader it should however be mentioned that, once AM is completed. 
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there are plans for the near future to develop a high-level 
language for AM, too, which would naturally ease the workload 
of the programmer. 

We now take a more detailed look at the issues and design 
of both the data abstractions and resource abstractions. 

B. ABSTRACT DATABASE DATA TYPES 

In this section we develop the abstraction of the database 
in detail along with all the data types needed to support it. 
In addition, we discuss issues concerning the design and 
examine how the specification captures the properties of the 
abstraction . 

One of the problems encountered while writing the specs 
for the database was, that in contrast to the previous speci- 
fications which mostly operate on single data types called 
3 

'atoms,' it became necessary to refer to the set theory which 
enables us to deal with single atoms as well as with strings 
of atoms. Since a database generally contains composed ele- 
ments rather than simple atoms, the 'set' seemed to be the 
right means to tackle this problem. However, a set does not 
allow the same element to be represented more than once, which 
would restrict the operations in an unintended way. We there- 
fore preferred to adopt the characteristics of a 'list,' where 
no similar limitations exist. This required the installation 
of an additional spec list that permits the more complicated 

^An 'atom' represents a problem solving abstraction and 
is discussed in Chapter VI. 
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operations on strings. The list will be described in detail 
in Sections C and D of this chapter. But first of all, we 
consider the basic steps of how to abstract the database. 

1 . Property-Identification and Value 

Each instance property of an object consists of a name/ 
value pair which from now on will be referred to as 'property- 
value,' containing a particular property-identification ( ' pid ' ) 
and a single value ('val'). Spec property_id expresses the 
properties of the 'pid' data type. A 'pid' can be a string of 
characters that qualifies as identifying notation for a data- 
base property. Different 'pids' are combined to a set forming 
the 'pidset' data type which can be considered as the descrip- 
tion of the domain for all legal names properties may take. 

Spec property_idset models this domain. The operation natur- 
ally performed on this data type is creating such a set, start- 
ing with an initial 'pid' and then extending it by repeated 
application of the union operator with the option of using the 
empty set as well as the universe of all sets. 

The values associated with a particular property are 
covered by spec value. This spec and the combination of its 
data type 'val' to a set, the new data type 'valset,' whose 
properties are described in spec valueset, are constructed in 
exactly the same way as the specs for 'pid' and 'pidset.' 

All values which may be meaningful in any context with the 
determined property names are permitted. For example, for 
the 'pid' age this could be the set of natural numbers from 1 
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to 100, while the ' pid' address might require a set of charac- 
terstrings. The joint operations 'unpidset' or 'unvalset' 
ensure that there are no redundancies in the same domain. 

But it is the programmer's responsibility to create the size 
and type of valuesets that fit his intentions best. In this 
stage it would be possible to build a domain containing dif- 
ferent types of data which, if carelessly applied later, could 
lead to an erroneous result. 

Both the 'pidset* and 'valset* data types provide a 
disjoint operation, and a test for membership and equivalence 
(relational operators) . Regarding the intersection and union 
operations, provision has been made for associativity and 
commutativity . 

2 . Property and Propertyvalue 

In order to specify a property in its entirety we need 
two parts: a 'pid' that describes the name of the property, 

and a corresponding 'valset' which determines the domain of all 
the values this particular property can legally have. A 
property is represented by sort 'prop' and is always constructed 
from the ordered pair 'pid' and 'valset' 

prop = (pid , valset) . 

Spec property lists this data type and the possible operations. 

To reduce a property to one of its two fundamental 
elements, the operators 'getid' and 'getvalset' have been 
introduced. While 'getid' returns the property name ('pid') 
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getid: prop --> pid, 



'getvalset' returns the domain ('valset') of the property 

getvalset: prop — > valset. 

These two operators can be considered as reversion of the 
create operator 'crprop.' In combination with the empty value- 
set a property may be created just be defining a certain name, 
leaving the final determination of the corresponding valueset 
unspecified for the moment. 

Spec propertyset provides the data type for different 
properties associated to a set and has a similar structure as 
spec property_idset or spec valueset. But since every property 
consists of the ordered pair 'pid' and 'valset,' by the 
'getidset' operator all the 'pids' involved and specified as 
'pidset' can be retrieved 

getidset: propset --> pidset. 

Defining the properties for the database in this way was the 
result of an analytic process which led to the understanding 
that a property indeed is composed of a single element iden- 
tifying its type, and a set of values for this type. Since 
the sequence is important, we can treat a property as an 
ordered pair of single elements. But following this definition, 
now a certain property does not make much sense for describing 
an object, because it can not be used as a characteristic 
criterion. For example, 

crprop: ' grade ' , ( ' A ' , ' B ' , ' C ' , ' D ' , ' E ' , ' F ' ) — > prop; 
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would result in the property [ ' grade ' , ( ' A ' , ' B ' , ' C ' , ' D ' , ' E ' , ' F ' ) ] 
where 'grade' equals the ' pid ' and ('A'j'B'j'C'/'D'^E','?') 
the 'valset.' Would it be meaningful to describe any object 
by this property? It certainly would not, because this is a 
general statement about the property 'grade' containing all the 
defined values a grade can consist of. A specific object, how- 
ever, should only contain a specific value that is character- 
istic for it. In Chapter IV we called such a combination a 
name/value pair or an instance property. Although we mentioned 
this subject before, it is our concern to illustrate the basic 
difference between a property and a particular propertyvalue . 

Sort ' pval ' in spec propertyvalue defines the data type 
to resolve the problem stated in the previous example. Opera- 
tor 'crpval' enables us to create the required instance of a 

property that itself serves as the basis for describing any 
specific object. Referring to the above given example 

crpval: 'grade', 'A' — > pval 

would now result in the propertyvalue " ' grade ' , ' A ' " which then 
can be used for any object that would meet this condition. 
Besides the relational operators for equality and membership, 
as for all composed data types, there are operations available 
which return either the first element of the ordered pair, 
'getpid' retrieves the 'pid' 

getpid: pval — > pid, 

or the second element which can be retrieved by the operator 
'getval' returning the corresponding value of data type 'pval' 
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getval : pval --> val . 



Since objects usually are described by more than just 
one propertyvalue, spec propertyvalueset was introduced. With 
its data type 'pvalset' it is possible to combine different 
property values into a set. This is the final step on our way 
towards defining an object which will be discussed next. In 
order to determine the different properties represented in 
such a propertyvalueset, the property names, or ' pids , ' are 
of major interest. They can be retrieved by the operator 
'getpidset' which accepts any 'pvalset' as input and returns 
the matching 'pidset' 

getpidset: pvalset --> pidset. 

Due to the fact that the data type 'pval' consists 
of the ordered pair 'pid' and 'val,-' and that the combination 
of distinguished 'pvals' forms a 'pvalset,' this new data type 
is also composed of a set of ordered pairs itself, namely the 
set of the ordered pairs 'pid' and 'val.' It therefore was 
necessary to add two distinguished membership operations, one 
for testing whether a given propertyvalue is contained in a 
particular set of propertyvalues 

mempvalset: pval, pvalset --> bool 

and the other for checking if a given propertyvalueset belongs 
to a certain propertyset which includes information about the 
'pids' involved as well as the domains for the corresponding 
values 
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mempset: pvalset , propset --> bool. 



Again, as for all sets, the union operator 'unpvalset' 
ensures that there are no redundancies, while the disjoint 
operator 'intpvalset' would retrieve property-values contained 
in both sets to be checked. Furthermore, the standard. opera- 
tions for associativity and commutativity have been included 
on principle in this more mathematical part of the specification. 

3 . Object and Objectclass 

As mentioned before, the essential element of the data- 
base resource is the object. Each of the previously discussed 
specifications represents an indispensable portion that finally 
enables us to express the data type 'obj' by means of these 
more elementary data types. Its properties are specified in 
spec object. An object can be considered just as a particular 
set of propertyvalues , each containing a distinct ' pid' and a 
' val ' 

obj = pvalset = [ (pid, val) ^ , . . . , (pid, val) ] . 

The function that initiates this operation is called 'crobj.' 

The kind or number of 'pvals' defining an object is of no 
interest for us at this point, although it will be later. So, 
theoretically, any combination of 'pvals' could’ be chosen to 
build up an object, even such containing the same 'pid' or 
' pval' more than one time which actually would be meaningless. 

But since the installation of a database is always preceded 
by a rather precise concept, the grouping of different objects 
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into classes then should eliminate the possibility of an inci- 
dently induced redundancy on ' pids . ' 

The reverse operation to creating an object is 
' getopvalset ' which returns the entire 'pvalset' defining the 
object 

getopvalset: obj — > pvalset 

while the operator 'getopidset' retrieves only the correspond- 
ing set of 'pids' 

getopidset: obj — > pidset. 

In general, the type of properties is considered more important 
for structuring purposes, as this criterion forms a good basis 
for hierarchically combining related objects to classes (compare 
Chapter IV, Section C) . We therefore did not, as the reader 
might have expected, introduce an analogous operation which 
would return all the values of a given object, but instead pro- 
vided the operator 'getoval' that only retrieves one single 
value associated with one particular 'pid' of the object 

getoval: obj, pid --> val . 

Provisions are also made for an equality operator 'eqobj' and 
a membership operator ' haspval ' which checks if a given ' pval ' 
is contained in a certain object. 

'Class' is the data type that represents a number of 
objects that are related in some kind to each other. This type 
has been discussed in some detail in Chapter IV. Its properties 
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are now specified in spec objectclass. If we want to insert 
an object into a particular class, this can be done by apply- 
ing the operator ' insob j 1 which takes a class and an object 
and returns a class now including the new object. We must, 
however, ensure that only appropriate objects, which means, 
with matching 'pids,' will be inserted. This problem is solved 
by defining an operator for retrieving the 'pidset' of a class 
( ' getcpidset ' ) which takes a class as input and returns the 
corresponding 'pidset' 

getcpidset: class --> pidset. 

Together with the above specified operator 'getopidset' that 
accepts an object as input and returns its 'pidset,' the 
following axiom takes care of this 

i,f eqpidset (getopidset (o) , getcpidset (c) ) = true () 
then 

insob j (c , o) = c ; 
else insobj(c,o) = undef; 
end if ; 

by determining whether the 'pidsets' of the object to be in- 
serted and of the class both are equal. If they are, then 
the object can be added, if not, the operation becomes unde- 
fined and the object can not be added. 

A similar approach was taken with the operator ' delob j' 
for the deletion of a selected object from a given class. It 
had to be ensured that any attempt to delete from a class some- 
thing not contained in it was discovered. To solve this 
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problem the membership operator 'memclass' used in the 
axiom 

if memclass (o , c) = true () 
then 

delobj (o, c) = c; 
else delobj (o,c) = undef; 
endif; 

to first check if the selected object is contained in the given 
class. This certainly is not a very efficient way of doing 
the deletion, but it avoids 'blowing-up' the machine by an 
operation that can not be handled. 

The situation where a class is itself contained in 
another can be managed by the relational operator 'subclass.' 
This provision may be useful when the hierarchical structure 
is of importance. In connection with the intersection opera- 
tor 'intclass' the boolean value of this relation can easily 
be determined: 

if intclass (c-^ , C2 ) = c-^ 
then 

subclass (c^ , c^ ) = true ( ) ; 
endif ; 

As in most of the cases the 'if-then' part of this axiom could 
be reversed and the axiom would still be meaningful. Here it 
becomes obvious that the decision, what axioms to include and 
which to omit is a rather difficult matter and depends widely 
on the view of the designer. But since there is no sound 
recipe for how to proceed, this condition may be a source for 
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potential errors not discovered while the specification is 
written . 



4 . Database 

The last data type, 'db,' defined in spec database 
represents the highest level and operates on all the data types 
previously discussed. So, we have now reached our goal of 
combining every single data type from 'pid' up to 'class.' As 
the reader might have expected, in order to constrcut a data- 
base one or more objectclasses must be available. This is a 
mandatory prerequisite since it would not make much sense to 
treat a couple of non-related objects like a database that 
always represents a particularly structured arrangement of data. 
Operator ' crdb ' allows us to create a database; it takes a 
'class’ as its only argument and returns a database. A 'class' 
can be extended to any required size by the union operator 
defined in spec objectclass. This method not only avoids 
meaningless redundancies but also ensures that each 'pid' con- 
tained in one of the subordinated classes will be contained in 
the database, too. 

Since 'db' is the data type of most interest for the 
application programmer, all the fundamental database operations 
have been provided in this specification. For example, 'getdb- 
pidset' returns the set of 'pids' comprised in the database, 
which cannot be different from those of the corresponding 
classes 

getdbpidset: db — > pidset. 
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This is expressed by the following axioms: 

getdbpidset (insclass (crdb (c]_) ) ,02) = 

unpidset (getcpidset (c^) , getcpidset (c^ ) ) ; 

which states that, if a new class c ^ is inserted into a data- 
base consisting of the class c-^, operator 'getdbpidset' would 
return the set of 'pids' equal to the joint 'pidsets' of c^ 
and c 2 a s determined in the right hand part of the equation. 

Operator 'retclass' enables us to retrieve a given class 
from the database, object by object 

retclass: db , class — > pvalset. 

This function is more difficult to express in axiomatic terms 

if and ( 

and ( 

(getopvalset (o) = pvs) , 

(memclass (o,c) = true ( ) ) 

) , 

( memdb ( c , d ) = true ( ) ) 

) = true ( ) 
then 

intpvalset (retclass (d , c) , pvs) = pvs; 
endi f ; 

Here three conditions need to be fulfilled to activate the 
final statement. First, a given object o must have a particu- 
lar 'pvalset' pvs, second, this object must be contained in a 
certain class c which itself has to be a member of the data- 
base d. Then the 'pvalset' pvs must also be contained in the 
database. So the intersect operation of all the 'pvalsets' 
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of this class c when retrieved from the database, and the 
particular 'pvalset' pvs must finally return precisely this 
pvs, since it is the only one contained in both the class and 
the object. 

Provision for another operator has been made that re- 
trieves an object whose 'pvalset' is matched by a given 'pval': 
'retobj' accepts a database and a particular 'pval,' and 
searches the database for objects being defined by this 'pval.' 
Corresponding objects are then returned 

retobj: db,pval — > obj . 

A queue mechanism operating in accordance with the 'first-in, 
first-out' principle manages the case should more than a single 
object be retrieved. The axiom 

if and ( 

and ( 

haspval (pv,o) , 
memclass (o , c) 

) , 

memdb (c , d) 

) = true ( ) 
then 

retobj (d,pv) = o; 
endif ; 

states that, when an object o with a certain 'pval' pv is 
contained in a class c which itself is contained in the data- 
base d, then, when objects having this 'pval' are searched for 
by operator 'retobj,' these objects will be retrieved. If 
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there is only one object meeting condition pv, it will be 
presented as soon as it is discovered; otherwise a number of 
objects will be put on the queue and can then be retrieved 
object by object. Although this principle is simple, it 
ensures that each object with matching conditions can be 
determined and is available to the programmer at the end of 
one search. 

The operator 'modobj' allows for changing a 'pval' of 
a given object, modifying it thereby. Three arguments are re 
quired: the database, the object itself and the new property 

value. The database could have been omitted as an argument, 
but it guarantees that there actually is a certain structure 
available. The hard part is to defect any case for which the 
operation might not be defined, for example, if the given 
object does not belong to the indicated database, or if the 
replacing 'pval' is of a different type than the original 
or its value not defined in the domain of the associated 
property. To check whether all these premises are met, five 
conditions had to be added that must be satisfied in order to 
legally carry out the operation. The following axiom deals 
with these problems : 

if and ( 

and ( 

and ( 
and ( 

memprop (pv,crprop (pd, vs) ) , 
mempidset (pd,getidset (prs) ) 

) , 
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(getopidset (o) = getidset (prs ) ) 



) , 

memclass (o , c ) 

) , 

memdb (c , d) 

) = true ( ) 
then 

modob j (d , o , pv) = d; 
else modobj (d,o,pv) = unde; 
endif ; 



Going line by line through this axiom, it is stated that 

1. the new 'pval' pv to replace the present one has to 

be contained in the property created from the 'pid' pd 
and the 'valset' vs, or in other words, since a 'pval' 
consists of a certain 'pid' and a single 'val,' the 
'pids' will be identical while the 'val' of pv is 
contained in the corresponding 'valset'; 

2. 'pid' pd must be a member of 'propset' prs; 

3. the 'pidset' of object o to be modified must be 
identical with the 'pidset' contained in 'propset' prs; 

4. object o must be contained in class c; 

5. class c must be a member of database d. 

If all these conditions are met, ' modob j (d , o , pv) ' is defined 
and the operation can be executed; otherwise it would be 
illegal and can not be carried out. In short, this axiom 
ensures before the operator can be applied, that the new 
propertyvalue may be inserted because the entered property_id 
is actually present in the object to be modified, and the new 
value is defined within the domain of the associated property. 
Thus, one instance of this property will be replaced by another 
instance also defined for the particular object. 
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The remaining operators for type ' db 1 are similar to 
the ones discussed for spec objectclass and are the relational 
operator for membership 'memdb' and the operator 'insclass' 
for the insertion of a class, respectively 'delclass' for its 
deletion. As analogously described before, a class can only 
be deleted if it is contained in the database; this is expressed 
in the axiom 

if memdb (c,d) = true ( ) 
then 

delclass (d,c)' = d; 
else delclass (d , c ) = undef; 
endif ; 

If a given class is not contained in the database, it can not 
be deleted and the operation is undefined. With the insertion 
of a new class this is not quite as simple: 

if and ( 

or ( 

memdb ( c^ , d ) , 
memdb (c^ , d) 

) , 

eqpidset (getcpidset (c^ ) , getcpidset ) ) 

) = true ( ) 
then 

insclass (d , c^ ) = undef; 
insclass (d , c 2 ) = undef; 
else if and ( 

and ( 

memdb (c^ ,d) , 
not (memdb (c 2 ,d) ) 

) , 
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not (eqpidset (getcpidset (c^) , getcpidset (C2 ) ) ) 

) = true ( ) 
then and) 

( insclass (d # C2 ) = d) , 

(getdbpidset (d) = unpidset (getcpidset (c^) , 
getcpidset (C2) ) 

) ? 

endif ; 

Here the axiom defines that if either one of two ob jectclasses 
c-^,C2 is already a part of the database d and both have the 
same set of property_ids ' eqpidset (getcpidset (c^) , getcpidset (C2 ) ) , ' 
then there is no way of inserting any of these classes since 
they are already represented. If one of the classes c^ is part 
of the database while the other (C2) is not and they do not have 
the same set of property_ids , which means they must be differ- 
ent then it would be a legal operation to insert the one not 
yet contained. The property_idset of the database must then 
be extended by the newly added 'pids'; this is done by the 
joint operator 'unpidset.' 

These operations define spec database and thereby the 
fundamental part of all the individual specifications required 

4 

for mathematically describing the database. The remaining 
portion of Appendix B represents the transition towards corres- 
ponding operations that finally can be translated into machine 
instructions . 
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C. SPEC PARAMETERIZATION 

The characteristic properties of a list allow us to des- 
cribe the essential database operations of retrieve, insert, 
modify, and delete in a convenient way. Lists not only provide 
a clearly structured method for treating strings of variable 
length but also support recursive operations, which proves to 
be very useful for searching the database. It is the purpose 
of this section to show how these basic operations can be 
managed by application of the list theory, while in the next 
section we describe its usefulness for our particular data- 
base design. 

This, however, should not be seen as the attempt to narrow 
the spectrum of possibilities for the implementor or to guide 
his attention into one specific direction, since our methodology 
focuses on representation independence. The only reason for 
choosing this approach is that it provides an evident way to 
express our intentions. 

Since the contents of our database can be considered as 
strings rather than as single atoms, it was necessary to make 
provision for this by introducing the additional spec list with 
data type 'elm. ' This spec is a representative of the earlier 
mentioned parameterized specifications. It was used to define 
the special list operations including the recursions which 
offer a convenient way to carry out searches. Spec list allows 
the treatment of all previously described specifications as if 
they were of type 'elm,' simply by using a combination of spec 
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list with each of the former specs. For example, by applica- 
tion of the first discussed spec property_id using 'list 
(property_id) , ' now the new spec pidlist can be created which 
enables us to treat the initial data type 'pid' as 'elm' and 
the operator 'eqpid' as 'eqelm.' This procedure has the advan- 
tage that we can stay within or continue with the logical 
structure of AM specifications as they were developed by Yurchak. 
[Ref. 2] and Hunter [Ref. 3] . It furthermore is a contribution 
to the clarity and simplicity of our work since we can adopt an 
available technique. 

The typical list operators are 'nullst' which returns an 
empty list, 'firstelm' which returns the first element of a 
given list, 'firstlst' which retrieves the first list of a 
given list of lists, and 'restlst' which returns either the 
remaining elements or lists of a given list, except the first 
one. The meaning of these operators is expressed in several 
axioms 

firstelm (makelst (k) ) = k; 

restlst (makelst (k) ) = nullst; 

where 'makelst' is itself an operator which takes a single 
element and returns a list containing this element as its 
only member 

makelst: elm — > list. 

Should a given list be empty, so that there is no first 
element or any rest, the application of these operators leads 
to an undefined result by the corresponding axioms. 
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In contrast to 'makelst,' the operator 'makenewlst' re- 
quires a list as an input and returns a list again. By this 
operator it then is possible to express the operation 'firstlst' 
in the following axiom: 

firstlst (makenewlst (1) ) = 1; 

thus operator 'makenewlst' has an important function in order 
to indisputably describe the meaning of operator 'firstlst.' 

In fact, it sometimes is necessary to define an additional 
operator just for the purpose of expressing an already 
developed operation in an unambiguous way. 

Operator 'catlst' allows us to concatenate two lists into 
one and also serves as a significant tool for illustrating the 
meaning of the previous operations. The following axioms give 
an example: 

firstelm (catlst (makelst (k) , 1) ) = k; 
firstlst (catlst ( 1-^ , 1 2 ) ) = 1, ; 
restlst (catlst ( 1^ , 1~, ) ) = 1 2 ; 

These are just a few representative axioms dealing with the 
fundamental list operations. Many more are required to actually 
express our intentions. They can be found in Appendix B. 

Again, we face the initially encountered problem of how to en- 
sure that we did not miss any axiom of importance which possibly 
could result in an unwanted operation. So there is indeed no 
guarantee that our perception of the specified resource is 
precisely what the specification describes. 
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Some other, not necessarily typical list operations also 
had to be introduced for the particular purpose of handling 
all the recently defined, database operations. Because these 
operators are more complicated they will be discussed in some 
detail in the following. Each of them requires searching the 
database first before it can be applied or successfully ter- 
minated. Consequently an iterating process was needed that 
could do the job. Due to its simplicity the recursive^ ap- 
proach was chosen, which in general requires a termination 
condition and a certain pattern that reduces the overall prob- 
lem to smaller, solvable subcases. So, what we actually 
created was an archetype for each of the functions, containing 
its syntax and semantics, where the recursive definition can 
be considered as the prototype (compare [Ref. 9]) . 

Operator 'deist' is a function that accepts two lists as 
an input and returns a list. The first list is the one to be 
deleted from the list of lists entered as the second argument 

e.g., deist! (l b ) , (l a ,l b ,l c ) ] — > (W /*V list */ 

Two conditions have to be met before this operator can legally 
be applied: The list from which we delete must not be empty, 

and the one being deleted must be contained in it, otherwise 
'deist' becomes undefined. The axiom 
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if or ( 

eqlst(l2^nullst() ) , 
not (memblst ( 1^ , 1^ ) ) 

) - true ( ) 
then 

delstd^,^) = undef; 
else if eqlst (1^ , f irstlst ( I 2 ) ) = falseO 
then 

makenewlst (catlst(firstlst(l 2 ) , deist ( 1^ , res tlst (1 2 ) ) ) ) 
else makenewlst (rest.lst (I 2 )) ; 
endif; 

takes care of these cases. The next step then is to find the 
particular list 1^ which shall be erased. The only way to do 
this is by testing list after list of I 2 for identity with 1^. 

If the one being examined ( ' f irstlst ( 1 ^ ) ') is not identical 
with the one to be deleted (1^) , it can not be thrown away but 
instead has to be saved, and the pperation must be repeated 
with the rest of list 1 2 - This is achieved by the 'else-if' part 
of the axiom, until the identity is finally reached. By the 
'else' part, only the rest of list I 2 is then concatenated to 
the previous portions of 1 .^, while the list searched for will 
be eliminated. 

Example : 

if or ( 

eqlst[ (l a ,l b ,l c ) , () ] , 

not (memblst [ (l b ) , (] a » l b , l c ) ] 

) = true() 
then 

deist [ (l b ) , (l a ,l b ,l c ) ] = undef; 
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since this condition does not hold in this example, the 
'else-if' part will be checked: 

else if eqlst [ (1^) , (1 ) ] = false() 
then 

makenewlst [catlst ( d a ) , deist ( (1^) , (1^, l c ) ) ) ] ; 
where 'deist' initializes the repeated application of the 
operation. During the second run the 'else-if' condition 
becomes true 

eqlst [ (l b ) , (l b ) ] = true ( ) 

and the 'else' part therefore is activated 

makenewlst (1 ); 

c 

this leads to the concatenation 
catlst (1 , 1 ) ; 

< 3 . 

which is the final result in this case. 



This operation still retains the necessary level of abstraction 
since it would work for every data of type list. The structure 
of the database, as described in the eleven specifications at 
the begining of this chapter, supports the application of the 
list theory. This issue will be discussed in the next section. 

Operator 'getlst' takes a list 1^ of lists and a particular 
list I 2 as input and returns the list corresponding to 



getlst [ d al 'l a2 'l bl 'l b2 ) / d bl ) ] > l b2 /* 1 i : llst i */ 

It is expressed in the axiom 



if or ( 

eqlst (1^, null st ( ) ) , 
eqlst (1 2 , nullst ( ) ) 

) - true ( ) 
then 

getlst ( lj , 1 2 ) = undef; 
else if eqlst ( firstlst ( 1^) , 1 2 ) = true() 
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then 

getlst ( 1 1 , 1 2 ) = f irstlst (restlst (lg) ) ; 
else if eqlst ( f irstlst ( restlst (lg )) d 2 ) = true () 
then 

getlst (1^/ 1 2 ) = f irstlst ( 1 1 ) ; 
else getlst(restlst(restlst(l^) ) , 1 2 ) ; 
endif ; 



The meaning may not be obvious at the first glance, so we will 

explain it. The underlying principle is that we consider a 

list of this type as a combination of several pairs of lists. 

Thus, entering a list of lists (1 gd^/l^gd^) an< ^ one P art 

(l^g) of such a pair shall result in retrieving the matching 

second part of the corresponding pair from the list(l , ,1 0 , 

1j 3 ^,1j j2 ) . Again, precaution has to be taken for cases where 

this operation can not be performed. For example, when either 

of the lists is empty, then 'getlst' becomes undefined. The 

axiom is constructed in such a way that always a pair of lists 

from the first list is checked against the second list which 

itself represents only one half of a pair. Should the first 

part of the list ('firstlst(l .,1 _ , 1. , , 1, „)') be identical with 

al a Z bl bZ 

the second list (l^g ) > then the matching part of the pair 

(' f irstlst ( restlst. ( 1 , ,1 n , 1, . , 1, 0 ) ) ' ) will be returned as the 

al a z bl b Z 

result. Should the second part of such a pair (' f irstlst 

(restlst (1 -1 , 1 0 , 1, n , 1, „ ) ) ' ) be identical with list (1. . ) , 
al az 01 Dz d 1 

then the first part of the corresponding pair will be retrieved. 
If no match occurs the 'else' condition applies, the recursion 
is activated and the remaining pairs from the first list will 
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be checked against the second list. So in case 1^ was not 

contained at all in 1^, list 1^ will eventually become empty 

and, since it is not possible to retrieve a part of a pair that 

does not exist in the given environment, the operation must 

become undefined at that time. This is exactly what will 

happen by means of the termination condition for the recursion. 

Example : 

if or ( 

eqlst [ ( 1 a ]_' 1 a 2' 1 bl ,1 b2^ ' ^ ' 
eqlst [ (l bl ) , ( ) ] 

) = true ( ) 
then 

getlst [ (l al ,l a2 ,l bl ,.l b2 ) , (l bl ) ] = undef ; 
since this condition is not true, the 'else-if' part will be 
checked : 

else if eqlst [ (l al ) , (l bl ) ] = true ( ) 
which is not true either, so the next 'else-if' condition will 
be checked : 

else if eqlst [ (l a2 ), (l bl ) ] = true ( ) 
since this- is false, the 'else' part is activated 
else getls t[ (1 bl ,1 b2 ) ' ^'bl* ] ; 

which initializes the repeated application of this operator. 

In the second run, the first ’else-if' condition becomes true 
else if eqlst [ d bl ), d b ^) ] = true ( ) 
so the following statement will be executed: 
then 

getlst [ (l bl , l b2 ), d b] ) ] = l b2 ; 
returning l b2 which is the list that corresponds with the 
second argument 1^ in the described example. 

The next operator, 'sofirstlst' (set of first lists), takes a 
list as input and returns a list or, more precisely, it requires 
a list of lists and gives a set of lists back 
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sof irstlst [ 1 , 
al 




This special function was introduced to manage the operations 
where a set of first lists shall be retrieved: 



if ltnat (lenlst (1) , succnat (succnat (zeronat ( ) ) ) ) = true ( ) 
then 

sofirstlst (1) = undef; 

else if eqnat ( lenlst ( 1 ), succnat ( succnat ( zeronat ())) ) 

= true ( ) 
then 

sof irstlst ( 1 ) '= f irstlst (1); 

else catlst(f irstlst (1) , sofirstlst (rest 1st (rest 1st (1) ) ) ) 
end if ; 



where the criterion for the operation to be defined is, that 
the list must have at least two elements that themselves are 
lists or lists of lists, which is stated in the ’if-then’ part 
of the axiom. This is so because it would not make sense to 
apply ’sofirstlst’ to anything else besides a list of lists. 
The termination condition will be reached when the list has 
been reduced to just two sublists (’else-if part). In all 
the other cases the first element of the first list ( ’ firstlst 
( first 1st (1 ))’ ) will be concatenated to the iterated operation 
’ sof irstlst ,’ now applied to the remaining portion containing 
all other lists except the first one. Thus, finally, this 
operator returns every first list from the sublists of list 1. 



Example : 



if [ lenlst ( 1 . , 1 

3. 1 



,1 a2 ,1 bl ,1 b2 



1. 0 ) < 2] = true ( ) 



then 



sofirstlst [1 

al 
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since the length of list 1=4, this condition does not hold 

and the 'else-if part is tested 

else if t lenlst d al » ! a2 ' ■'■bl' 1 b2^ = 2 3 = true ( ) » 

which is not true either, so the 'else' part is applied: 

else catlst[l , , sofirstlst (1, , 1, ~ ) ] ; 

al bl t>2 

thereby initializing the repeated application of the operation. 
In the second run, the 'else if' condition becomes true, 
since (l b ^,l b2 ) now has length =2, so the ’then' statement 
is applied: 

sofirstlst (l bl ,l b2 ) = l bl ; 
which leads to 

catlstll al ,l bl ] - <l al .l ol > 

thereby returning the set of first lists from the given 
list 1. 

The last operator to be discussed is called 'retobjlst'; it 
takes two lists as an input and returns a list. It was intro- 
duced with the intention to retrieve all the lists which meet 
a particular condition 



retobjlst t ( d al ' 1 a 2 ' * 33 ) ' (l bl' 1 b 2 J ' ‘ 1 cl' 1 c 2 ' l c 3 > ^ ' ^ 1 b 2 ) ^ 






(1 bl' 1 b2>- 



So in some sense, this is the most useful operation because it 
allows us to search a big list for certain sublists without 
having to remember all the details about the sublists. The 
axiom is short: 



if eqlst ( f irstlst ( 1^ ) , nullst ( ) ) = true ( ) 
then 

retobjlst (1^, 1 2 ) = nullst (); 
else if intlst ( 1 2 , f irstlst ( 1^ ) ) = 1 2 
then 

catlst(firstlst(l-| ) , retob j lst(restlst(l-^) ,1 2 )) ; 
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else retob j 1st ( restlst ( 1-^ ) , 1 2 ) ; 
endif ; 

t 

and states that, if the overall list to be searched (1^) for a 
sublist is empty, this list can not be contained in it. Thus, 
the result is the empty list itself ('if-then' part), which 
also serves as the termination condition for the recursion. 
Should the intersection between the entered list 1 2 and the 
first list of 1. be equivalent to 1 2 , the entire first list of 
1^ will be concatenated to the repeated operation now applied 
to the remaining lists of 1^ ( ' else-if-then ' part). This en- 
sures that the list will be completely scanned since more than 
one of the contained sublists could meet the given condition 
comprised in 1 ^, If 1^ does not occur in the particular list 
being searched at the moment, the intersection of both can not 
be equal to 1 2 , and the 'else' part is activated. In this 
case the operation continues without saving the non-matching 
portion of 1-^. When finally terminated, a concatenated list 
is available that comprises every single list of 1^ meeting the 
predefined requirement. 



Example : 

if eqlst [ (l al , l a2 , l a3 ) , ( ) ] = true ( ) 

since this first list of 11 is not empty, the condition does 
not hold and the 'else-if' part is tested 

else if intlst[(l b2 ),U al ,l a2 ,l a3 )] = l fa2 
does not hold either, so the 'else' part is applied: 

retob j 1st [ ( d 51 ' 1 b2 ) ' ( 1 cl ' 1 c2-' 1 c3 ) } ' (1 b2 } ] 
which initializes the repeated application of ’retobjlst.’ 

In the second run, the 'if' condition is still not true, so 
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the 'else-if' part is tested 

else if intlst [ (l b2 ) , (l bl , l b2 ) ] = l b2 
since the condition holds, the 'then' statement is executed 
then 

cat 1st [ (l bl , l b2 ) , retob j 1st ( d cl , l c2 > l c3 ) , d b2 ) ^ ^ ‘ 
which, again, initializes 'retobjlst.' 

In the third run, this leads to the application of 
retobjlst [ () , d b2 ) J 

but now the 'if' condition is true and the entire operation 
results in the concatenation of [ ( l b ^ ) , (l b2 ) ] with the 
empty list, which gives us (l b ^ , l b2 ) as the final result. 

As discussed earlier, the queue mechanism has to be used as 
an intermediate storage process to ensure that none of the 
retrieved lists will be lost. By means of parameterization 
all the operators described in the mathematical part of the 
specification (spec property_id through spec database) can be 
applied using the adequate list operations. This is achieved 
by short hybrid specifications (spec pidlist through spec 
dblist) which combine the parameters defined in 'spec list' 
with the corresponding operators of the original specifications, 
giving access to all the operations of data type '1st. ' 

D. THE LIST STRUCTURE APPLIED TO DATABASE DESIGN 

In this section we describe how the application of the list 
theory supports the fundamental database operations. Since 
the structure of the abstract database can be compared with a 
large list, this concept will be discussed in more detail. 
Starting with the basic elements ' property_id ' and 'value,' 
each of the related data types may be considered as forming a 
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list containing just the single element <pid> or <val>, while 
their sets are represented by lists consisting of as many sub- 
lists as required, for example, 

<<pidl> , <pid2>> or <<vall> , <val2> , <val3>> . 

Consequently, a 'property' which is defined by a 'pid' and a 
'valset' can be expressed by means of a list containing these 
two major sublists as elements, where the second list is itself 
composed of a number of single lists: 

< <pid>,< <vall> , <val2 >,..., <valn> > >. 

Adding another ' < ' at the beginning and one ' > ' at the end 
combines several properties into a ' propertyset . ' Applying 
this technique to ' propertyvalue ' which represents an instance 
of a property, the resultant looks like the following: 

< <pid>,<val> > 

and the corresponding set can be created by combining the 
necessary number of adequate ordered pairs 

< < <pidl> , <vall> >,< <pid2> , <val2> <pidi> , <vali> 

To construct an 'object.' is now straightforward since the ob- 
ject is nothing more than a particular ' propertyvalueset ' it- 
self. The 'ob jectclass ' then can be considered as a number of 
different objects put into the same list. But caution has to 
be taken that we do not violate our definition of a class. 

Since objects can only be grouped together if they are struc- 
tured in a similar way, it is mandatory that they contain exactly 
the same number of corresponding 'pids.' 



120 



A 'class' can be expressed by a list of the form: 



< < < <pidl > , <valll> <pidi> , <valil> > >, 

♦ 

< < <pidl> , <vall2 > <pidi> , <vali2> > >, 

• • • • • • • 

• • • • ♦ • • 

• • • • • « e 

< < <pidl> , <vall j > <pidi> , <vali j > > > >; 

where the kind and number of 'pids' is the only criterion for 
associating a given object to a certain class, while any 'value' 
necessary for describing an object can legally be attached to 
a 'pid' as long as it is defined in the appropriate domain. 

Finally, the database can be treated like a big list con- 
taining several lists of the class type just described, where 
the same criteria must be met on a higher level. To see how 
an operation on this list structure works, let's consider the 
disjoint operator for 'pidsets': 

intpidset (pidsetl , pidset2 ) --> pidset3; 

where, for example, 

pidsetl = < <pidl> , <pid2> >; 

pid.set2 = < <pidl> , <pid3> >. 

Invoking the parameterized spec pidsetlist gives us access to 
both spec list and spec property_idset . 'Intpidset' is then 
replaced by 'intlst' which by substitution leads to the 
operat ion 

intlst.(< <pi.dl> , <pid2> >,< <pidl > , <pid3> >). 

Since operator 'intlst' is handled by the recursive axiom 
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if or ( 

(eqlst ( 11 , nullst ( ) ) = true ( ) ) , 

(eqlsi;(12 ,nullst () ) = true ( ) ) 

) = true ( ) 
then 

intlstlf irstlst ( 11) , 12 ) = nullstC); 
else if memblst ( f irstlst ( 11) , 12 ) = true ( ) 
then 

catlst(firstlst(ll) ,intlst(restlst(ll) ,12) ) ; 
end if ; 

first the termination condition is checked, which means, if 
either of the two lists is empty then the intersection must 
be equal to the null-list ('if-then' part). In our particular 
case they are not empty, so the 'else-if' part will be tested. 
Since the first list ( ' <pidl> ' ) of 11 ( ' < <pidl> , <pid2 >> ' ) is 
contained in 12 ( ' < <pidl> , <pid3 >> ' ) , this condition holds and 

the concatenated list ( ' catlst [ <pidl> , intlst ( ( <pid2 > ) , ( <pidl> , 
<pid3>))]') is created where 'intlst' invokes a recursive opera- 
tion on the rest of 11 ('<pid2>') and 12 ( ' <pidl > , <pid3> ' ) . 

This time, since neither the 'if' nor the 'else-if' part is 
true, the 'else' condition is applied which leads to a repeated 
operation on the rest of 11 and on 12: 

intlst [<>, (<pidl>,<pid3>) ] . 

Now the 'if' part of the axiom becomes true which returns the 
empty list. This results in the concatenation 

catlst (<pidl> , <>) 

and gives '<pidl>' as the intersection of 11 with 12. 
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E. LIST RETRIEVAL 

In the previous sections we developed the abstractions of 
the database resource and discussed the set of operators that 
apply to database programming. In AM (version 2.0) the 'state' 
of the machine consists of the aggregation of the memory, 
register, stack cell contents, display register and monitor. 

We will now extend the 'state' to include the new entity 'queue.' 

1 . Background on the Processor Resource 

For a better understanding of the applied extension, 

in the following paragraph a brief description of AM, taken 

from Hunter [Ref. 3], will be presented. 

In AM (version 1.0) the five primitive data types, 

boolean, natural, integer, character, and string, form the 

atomic data types and are referred to as 'atoms.' Yurchak 

[Ref. 2] as the implementor of AM discussed the impact of the 

relationship between the data and a conventional machine on 

portability issues in detail, and identified the following 

properties of AM which were used to reduce the "semantic gap" 

and give AM its uniqueness: 

in the organization of primary storage, the next 
logical data item is in the next logical address; 

except as formally specified, no data type may be 
accessed in any way, as another data type; 

given any arbitrary logical address, the value stored 
there and its type can always be determined. 

The processor portion of AM is an abstraction of a conventional 

"Von Neumann" machine with some unconventional properties. 

The only machine element is called a 'value.' All data 
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primitives (atoms) map into values. Spec typing, as introduced 
by Hunter, describes the relationship of 'values' and 'atoms.' 

As an illustration of this relationship consider the inter- 
sect operation on two 'pidsets.' We fetch the value represen- 
tation of the first 'pid' of each set from two registers, and 
convert each value to its 'pidset' atom with the ' atomofpidset ' 
operator. The ' pids ' are intersected in accordance with the 
'pidset' data type, and the resulting 'pid' is converted back 
into a value with ' valofpidset ' for storage into a register. 

The operation will be continued recursively until both 'pidsets' 
are completely intersected. 

Primary storage is an array of one or more memory seg- 
ments, each of which may contain an arbitrary number of cells. 
Each cell is capable of "containing" any legal data value. 

Both programs and data may reside together in a single segment. 
For high speed storage, there are one or more register seg- 
ments, each of which contains an arbitrary number of registers. 
AM also has one or more stacks, a heap, a crude file system, 
and now a queue. Again, every register, stack and queue cell 
is capable of containing any type of data. 

The basic atomic data types are augmented by several 
others needed for the execution of programs. These are in- 
structions and memory, register, stack, file addresses, and 
the queue . 

2 . The Queue 

The value representation of the new data types 'pid,' 
'pidset,' 'val,' 'valset,' 'prop,' 'propset,' 'pval,' 'pvalset.,' 
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'obj,' 'class,'and 'db,' may be placed in any memory, register, 
or stack cells with one exception: whenever a set of 'pids,' 

'vals,' 'pvals' or 'objs' will be retrieved, they can not be 
displayed until they are first placed in the queue. The con- 
cept of the queue is similar to a stack. Since we do not want 
the programmer to have access to the "inside" of the queue nor 
want to provide facilities for altering the queue in any way, 
we make its use only available for the very special purpose 
of acting as a buffer for the data retrieved from the database 
so it can be returned to the programmer when a search is com- 
plete. The reason for introducing the queue is that the order 
always matters in a database. Thus, a stack which reverses the 
sequence between inputs and outputs would not work for this 
case. The queue preserves the order in which data is entered, 
and although queue operations are more difficult to specify 
than the stack operations, it finally was adopted. 

To make the queue mechanism operational in a similar 
way as the stack, instructions were installed for opening/ 
closing and reading/writing ('spec instructions'), while the 
operations for defining the state of the queue and their meaning 
were added to 'spec amstate. ' The program portion is described 
in 'spec am' which makes the queue an integrated part of AM. 

The database resource can be invoked by the operator 
' opendb ' which requires a characterstring as identifier, a 
database, a state, and returns a state. Provision for closing 
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the database is made by the operator 'closedb' which 
a database and a state as input and returns a state, 
terminating the access. 



requires 

thereby 



126 



VI . IMPLEMENTATION 



At present, only the original AM, version 1.0, is imple- 
mented and operates as a finite state machine interpreter. It 
comprises approximately 12,000 lines of C code, including the 
assembler. Developed by Yurchak, the overall concept for the 
assembler is as simple as it is effective. A text file repre- 
senting an assembly language program is translated by the 
assembler into a relocatable object module. A loader, part of 
the AM interpreter,- then loads this object module into the 
appropriate cells, and AM executes it. The reader is referred 
to Appendix C for more details about the assembler. 

Since Yurchak [Ref. 2] as the originator provides a complete 
description of the AM implementation, we will repeat major 
portions of his work but also consider points of interest found 
in Hunter’s [Ref. 3] description of the version 2.0 extension 
while finally adding some examples and discussion of our latest 
modification towards AM, version 3.0. 

For time reasons, neither the bit-mapped display nor the 
database resource have actually been implemented. Rehost.ing the 
original AM, version 1.0-Unix from a VAX 780 to a Zenith Zl.OO 
microcomputer by Hunter manifested once again all the typical 
difficulties known as "the portability problem." This rehost- 
ing required approximately 350 functions to be renamed 
throughout the 12,000 lines of code, since the compiler and 
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linker now used operate on shorter character names only. 

Another problem Hunter faced during the re-implementation of 
version 1.0 was that, although the Unix C compiler allowed 
passing of structures by value, the Lattice C compiler for the 
Zenith version does not, so the entire program had to be 
converted to passing structures by pointer. Thus major parts 
of the initial AM had to be modified or rewritten by Hunter. 

But despite these problems usually encountered when porting 
software, the number of test programs developed for the Unix 
version run on the Zenith Z100 with the same results. So far 
the assembler has been revised to handle the full extension 
for both versions 2.0 and 3.0, including all new data types, 
the resource extensions, plus some additional operators for the 
original data types, as mentioned before. The machine itself 
however, has not yet been extended to handle the new data types 
introduced by the gradual modification. This remains for 
some future work. 

After this description of the present state of the AM 
development, we will now continue with the overview of the 
implementation. There are four main areas: the representation 

of data types, the mapping of operators in the specification to 
functions in the interpreter, the handling of errors, and 
the execution of a program. 

A- IMPLEMENTING DATA TYPES 

Since it provided an easy translation from the specifica- 
tion, C was adopted by Yurchak as the corresponding programming 
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language for AM. But as he states in his work, another 
language, like LISP might have done the job as well. 

AM is a tagged architecture. Each data element or value 
must be self-descriptive. As Hunter points out, it is impor- 
tant to realize the distinction between an atom which corres- 
ponds with a data type, and a value. In contrast to an atom 
that is referred to as sort in our specifications and repre- 
sents a problem solving abstraction like 'pid' or 'obj' for 
the database, a value embodies a machine element. Furthermore, 
an atom is representation independent and keeps its level of 
abstraction, while a value is the specific representation of 
such an atom. Representation independence is achieved by cer- 
tain conversion functions (Appendix B) that map all atoms into 
appropriate values and vice versa. This translation technique 
enables us to determine the type of a value solely from the 
value itself, which is one of the distinct properties of AM 
and gives the machine its tagged architecture, introduced to 
ease the "portability problem." The most likely construct to 
provide this feature is a structure (record) . 

Each atom is represented in C-language as a structure con- 
sisting of a 16-bit tag field, and a value field. The size of 
the value field varies with the type. Each sort in the speci- 
fication, as the equivalent to an atom, is assigned a 16-bit 
code. Whenever an atom i.s created, or copied, it is tagged 
with the appropriate code. Figure VI . 1 lists some fragments 
from the header files used by our interpreter and represents 
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the 'natural' data type which has a simple value field. 

Hunter [Ref. 3] compressed the initial term 'NAT_TYPE' to the 
handier ' T_NAT ' for the reasons given above. 

#define T_NAT 0x0002 /*natural type tag*/ 

typedef unsigned intnat; 

typedef struct { 
short type; 
nat val; 

} NAT; 

Figure VI . 1 . Type Definitions for Natural 

By using a fixed size tag field as the first field in each 
record, we build in some additional robustness since, even 
in the event of a mistyped structure being copied into the 
formal parameter of a function, we can rely upon the first, 
word to be a valid code (the type) . 

The next step is to describe the structure for machine 
values that must be capable of containing any atom. To manage 
this problem, Yurchak introduced the union operation which 
involves every single sort defined in the specifications so 
that any atom can be represented by the value structure. Due 
to the "Z100" characteristics, the value structure is divided 
into portions of two bytes for the tag field and four bytes 
for a pointer; the data type's value will be represented 
either directly in such a value field or, if it can not be 
expressed within the space of the four bytes available, 
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a pointer to its real location is used. String and list struc- 
tures are examples that use pointers since their size is varia- 
ble and usually large. * 

Figure VI . 2 shows the concept of the union structure for 
machine values VAL. Because the number of data types increased 
very much in the latest modification of AM, only a sample of 
the values actually present is given. Hunter [Ref. 3] also 
notices that INSTR itself represents a VAL pointing to another 
VAL which contains the instruction's opcode. By this tech- 
nique it becomes possible to fetch and store instructions, 
thereby allowing us to put a program into memory and to execute 
it. 

The primary physical resources are also defined as struc- 
tures. A sample of these resources is presented in Figure VI . 3 . 
Registers, display registers, memory and stacks are represented 
as arrays of arrays of pointers to values. The reader should 
note that a simple change to the constants in the header files 
can completely alter the configuration of the machine. We 
can specify an arbitrary number of arbitrary long memory, 
register and display register segments, as wel.l as different 
sizes for an arbitrary number of stacks and the queue. Data- 
base and file are represented as an array of structures, with 
the files containing an input/output buffer in addition to the 
status information contained in both. The number of separate 
databases or the number and type of files can be changed by 
recompiling the corresponding module of the interpreter. 
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typedef short opcode; 

typedef struct { 
short type; 
union value *val; 
} INSTR 



typedef union 


value { 






short 


type; 






opcode 


opcdval ; 


/*this is the compressed 


version 






of the initially used term 






1 opcodeval ' */ 




BOOL 


boolval ; 


/*starting here the data 


types 


I NT 


intval ; 


are listed*/ 




FONT 


fontval ; 






LIST 

• 


listval ; 






♦ 

MAD 


madva 1 ; 


/*memory address*/ 




QADDR 


qadd.rval ; 


/*queue address*/ 




INSTR 


instrval ; 






MOP 


mopval ; 


/*monadic operator*/ 




DOP 


dopval ; 


/*dyadic operator*/ 





} VAL; 



Figure VI . 2 . 



Machine Values 



typedef struct { 
int size; 
VAL * * va 1 ; 
} memseg; 

typedef struct { 
int size; 
int sp; 

VAL * * va l ; 
} stkseg; 

typedef struct { 
int size; 
VAL * *val ; 
} qseg; 

typedef struct { 
int st.at; 
int mode; 
int type; 
int val ; 

} fileseg; 

typedef struct { 
int stat; 
int val; 

} dbseg; 



#define_NUMMEMSEG 1024 
#def ine_NUMSTKSEG 1 
#define_NUMQSEG 1 
#def ine_NUMFILES 16 
#def ine NUMDB 1 



memseg_mem [_NUMMEMSEGJ = { 

1024,0 

1024.0 } ; 

stkseg_stk [_NUMSTKSEG] = { 

512.512.0 } ; 
qseg_q [ NUMQSEG] = { 

512,512,0 } ; 



,/*memory segment*/ 



/*stack segment*/ 



/*queue segment*/ 



/*file segment*/ 



/*database segment*/ 



/*defined for 1 database*/ 



Figure VI . 3 . The Physical Resource 
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With respect to the characteristic requirements for re- 
trieving selected contents from the database, the queue was 
provided to act as a buffer. Since this is the primary reason 
for the queue, its accessibility has been limited to serve just 
this purpose. There are in fact only three ways of accessing 
the queue, either directly or via main memory and register 
operations that directly lead to the physical address of the 
data. The database must be opened similar to a file in order 
to perform the desired operations, and must be closed again 
when the operations are terminated. 

B. MAPPING OPERATORS TO FUNCTIONS 

It seems natural, although incorrect, to look at the 
operators in a spec as functions. However, in the implementa- 
tion, this makes perfect sense. Figure VI . 4 lists the code 
for the AM module which implements the boolean type. The 
header files which provide the constant definitions are omitted 
here. Notice that, where possible, we rely upon the operations 
provided by the C language, rather than slow down an already 
slow interpreter with axiomatic implementations of the 
operators . 

As the implementation proceeds to more complex specifica- 
tions, the program relies less upon C and more upon the opera- 
tors which we have defined. In fact, the more complex operators 
are implemented as calls to previously defined functions which 
almost directly mimic the axioms from which they are derived. 
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BOOLtrue = { T__BOOL,l }; /*the initially used BOOL_ 

TYPE was replaced by the 
more complex term T_BOOL*/ 

BQOLfalse { T_BOOL , 0 }; 

BOOL *not (a) 

BOOL a ; 

{ 

BOOL *tmp; /*'tmp' was installed by 

Hunter*/ 

tmp = (BOOL*) tmalloc (sizeof (BOOL) ) ; 
tmp->type = T_BOOL; 
tmp->val!= a->val; 
return (tmp) ; 

} 

BOOL *and(a,b) 

BOOL * a , * b ; 

{ 

BOOL *tmp; 

tmp = (BOOL* ) tmalloc (sizeof (BOOL) ) ; 
tmp- > type = T_BOOL; 
tmp->val = (a->val&&b->val ) ; 
return (tmp) ; 

} 

BOOL *eqbool(a,b) 

BOOL *a,*b; 

{ 

BOOL *tmp; 

tmp = (BOOL*) tmalloc (sizeof (BOOL) ) ; 
tmp- > type = T_BOOL; 
tmp->val = (a->val == b->val) ; 
return (tmp) ; 

} 

BOOL *nebool(a,b) 

BOOL * a , * b ; 

} 

BOOL *tmp; 

tmp = (BOOL*) tmalloc (sizeof (BOOL) ) ; 
tmp- > type = T_BOOL; 
tmp->val = (a->val != b->val) ; 
return ( tmp) ; 

} 

BOOL *or (a , b) 

BOOL *a,*b; 

{ 

BOOL *tmp; 



Figure VI . 4 Operator to Function Mapping for Type BOOL 



135 



tmp = (BOOL* ) tmalloc ( sizeof (BOOL) ) ; 
tmp->type = T_BOOL; 
tmp->val = (a->val I b->val); 
return (tmp) ; 



Figure VI . 4 (CONTINUED) 



C. ERROR HANDLING 

The method of treating errors was entirely revised by 
Hunter. All errors in the specifications are now described with 
the 'undef' operator. By definition, that makes all errors 
fatal, but they need not be. Those errors which are not, must 
then be defined explicitly in the specification. As remarked 
earlier, a more detailed treatment of errors would be an area 
for further study. 

AM flags most errors in the operators which perform data 
conversions. This is a natural place for this to occur, since 
it is difficult to see how the type of a data element may be 
changed at any other time. Figure VI . 5 shows a fragment which 
implements the ' property_id ' conversion routines. The routine 
'error' does not return, but terminates execution after writing 
the error message to 'stderr. ' Notice that, even if a much 
larger structure was passed to 'atomofpid' or 'valofpid,' the 
error would be detected and handled gracefully. 

This type of error checking is also performed in the func- 
tions which implement data operations. 
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/*short form for atomofpid*/ 



PID *atpid (v) 

VAL *v; 

{ 

PID *b ; 

if(v->type != V_PID) /*reduced term for PID_VAL*/ 

error ("value not of type PID -%x", v->type) ; 
b = (PID* ) tmalloc ( sizeof (PID) ) ; 

b- > type = T_PID; /*reduced term for PID_TYPE*/ 

b->val = v->pidval . val ; 
return (b) ; 

} 

VAL *vlpid (b) /*short form for va.lofpid*/ 

PID *b; 

{ 

VAL *v ; 

if (b->type != T_PID) 

error ("atom not of type PID -%x" , b->type) ; 

V = (VAL* ) tmalloc ( sizeof (VAL) ) ; 
v- >pidval . type = V_PID; 
v->pidval . val = b->val; 
return ( v) ; 

} 



Figure VI . 5 . Error Handling Routine for Property_id Type 



D. EXECUTION 

The final point of interest involves actually executing a 
program. The method is also illustrative of the way in which 
the program mimics the axioms of the specification. Here, 
too, we resort to subterfuge to implement in a finite way a 
specification which could require the expenditure of an infinite 
resource (an implied stack in this case) . The problem is the 
corecursive relationship between the functions ' xeq ' and 
'prog.' We eliminate this problem by never actually returning 
from 'xeq.' We rely on a dangerous but effective C idiom, 
'setjmp' and 'longjmp.' Figure VI . 6 illustrates this. 
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main (argc , argv) 
char *argv[]; 

{ 

int ap; 

for (ap=l; ap<argc; ap++) { 
if (*argv[ap] == 

if ( * (argv [ap] +1) == 
traceflag = 1; 
xtraceflag = 1; 

} 

if ( * (argv [ap] +1) == 
traceflag = 1; 

} 

} 

initiam ( ) ; 

amload ( ) ; 

set jmp (_context) ; 

Q = prog (&_pc,Q) ; 
exit ( 0 ) ; 

} 



/*check for toggles*/ 
' x ' ) { 

/*added by Hunter*/ 

' t’ ) 



/*main body*/ 



STATE prog(m,q) /*program for prog*/ 

MAD *m; 

STATE q; 

q = xeq (atins tr ( f etchm (m , q) ) , m , q) ; 

/*short term for atomof instr */ 



STATE xeq(i,m,q) /*program for xeq*/ 

INSTR * i ; 

MAD *m; 

STATE q; 

{ 

opnd *p ; 

if ( i- >type ! =T_INSTR) /*short term for INSTR_TYPE*/ 

error (" attempt to execute non-instruction -%x" , i->type) 
p = i->val; 

switch (getopcode (p [ 0 ] . opcodeval ) ) { 

/*a case and semantics for each valid opcode goes 
here*/ 
default : 

error ( "attempt to execute an illegal instruction -%x" , 
p[0] .opcodeval) ; 

} 

longjmp( context,l); 

} 



Figure VI . 6 . Program Execution 
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In 'main,' 'initam' configures AM and invokes all of the 
initialization operators. 'Amload' loads a program from secon- 
dary storage into the appropriate cells as directed by the 
linker directives in the object module. 'Setjmp' then saves 
the state of the "real" machine. The variable ' _pc ' is the 
program counter which is set inside 'amload.' Now everything 
is set. The program is loaded and ready to run. 

'Prog' is now called. Notice that 'prog' simply invokes 
'xeq.' Recall now the axiom which defines the semantics of 
execution : 

prog(m,q) = xeq (atomof instr ( f etchm (m, q) ) ,m , q) ; 

The value of a language which permits usefully long names is 
obvious in this case. Within 'xeq' a large case statement 
decodes the instruction and executes it according to the 
semantics provided for that case. This semantics 'is very closely 
modeled on the axioms in the specification. Figure VI . 7 shows 
one such case and its accompnaying semantic action. 

case IM M M; 
q = storem( 

f etchm ( 

&p [ 1 ] . madval , 

q 

) , 

&p [2 ] . madval , 

q 

) ; 

_pc.val = nxtmad (m) ->val ; 
break 

Figure VI . 7 . The Semantics for 'mov_m_m' 



/*val of memaddr pointed to 
by p [1] */ 

/*q : state*/ 
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Now compare Figure VI . 7 to the axiom for mov_m_m. 

xeq (mov_m_m (ml ,m2 ) , m , q) = 
prog ( 

nxtmad (m) , 
storem ( 

f etchm (ml , q) , 
m2 , 

q 

) 

) ; 

The similarities are not accidental. This should make the 
point that it is beneficial for the implementation language 
to permit such a close modeling of the specification. Obviousl 
this made the implementation easier to write, debug and 
understand . 



E. DATABASE IMPLEMENTATION ISSUES 

Similar to a file system, the database consists of two 
major parts: the information contained in it and the program 

that allows the user to manipulate this implementation. Once 
implemented, both program and content of the databases are 
rather fixed, although the information part can gradually be 
changed by iterated application of the appropriate commands. 
Thus in general the user is limited to retrieving or modifying 
the stored information, but this is the main purpose of a data- 
base. Should a conceptual change of the contents become neces- 
sary after a while, it is more convenient to revise the kind 
and arrangement of the data, and let the entire database then 
be re-implemented by an application programmer. 



Theoretically, there exist no boundaries for the size of 
our abstract database, which means objects can be defined by 
any number of propertyvalues , and classes may contain any 
number of objects. But in reality we cannot ignore the capa- 
bility of the available physical resources. Since databases 
tend to increase rapidly, the capacity of the attached storage 
device will set the natural limit. 

Practically speaking, a user would need a DDL tool to 
effectively create a database, just as a compiler would be 
needed to effectively write programs for AM. The purpose of 
this thesis however, is to give a precise specification of the 
low level resources needed for a database. 

The particular commands accessible by the user will be 
fully integrated into the AM instruction set. They ma.inly 
consist of the operations described in spec objectclass and 
spec database and are considered sufficient to perform all the 
necessary data manipulations. The operators provided permit 
the insertion and deletion of an object into/from a given class, 
the update of an object by modification of its contents, and 
the selection of one or more objects in accordance with a 
predefined condition. As soon as the database part of AM is 
invoked (instruction ' opendb ' ) these commands can be applied 
to the contents representing this database after they are 
brought into main memory first. For any change, data are 
fetched from their memory location, loaded into a register, 
and stored back when the operation is completed. After 
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termination of the desired activities the database must be 
closed (instruction 'closedb') and the data will be transferred 
back to secondary storage. This procedure ensures that the 
data residing in secondary storage at the end of the operation 
always represent the actual state of the database. A presorting 
of data outside main memory is not feasible, since we do not 
presume the existence of an additional processor which is usually 
known as back-end computer. 

To select an object on the basis of a certain entity by 
which it is defined, called 1 propertyvalue ' ( ' pv ' ) in our 

terminology, the characterizing 'pv' will be loaded into a 
register as a comparand. Identified by the corresponding 
' property_id ' of this 'pv,' the class possibly containing the 
required object is then localized and the entire 'pv' set of 
its first object will be loaded into a separate set of registers. 
If a match occurs between the comparand and the register con- 
taining the adequate 'pv' of the object, the total 'pv' set is 
copied into the queue and the next object will be loaded. If 
no match takes place the procedure will be continued without 
storing the object in the queue. V7hen the entire class has 
been searched, the 'select' operation terminates and the resul- 
tant object (s) can be read from the queue. The state of the 
database will not be changed by this operation since only a 
partial copy is taken. But it can not be excluded that none of 
the objects would meet the criterion searched for. In this 
case no copy will reside in the queue and the returned 'pv' 
set is empty. 
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In contrast to the 'select' operation, which can be con- 
sidered as a read function, insertion, deletion, and modifi- 
cation actually do change the given state of the database, so 
these operations are a little more complicated. Inserting 
a new object requires, besides the 'pv' set that defines it, 
the class to which it is inserted. This technique ensures that 
no object accidentally will be inserted which is not attached 
to a certain class. Without this restriction, the structure 
of the database could be changed in an unacceptable way. When 
the class has been identified by comparison of the correspond- 
ing ' property_ids ' the new object will be added at the end of 
that class. An error handling routine is invoked should the 
required class not exist. 

At this point the question must be answered where the special 
identifier or 'key,' mentioned in a previous chapter, would 
best fit. Such a device is necessary to distinguish between 
' pv ' sets which incidentally are identical, although they may 
represent different objects, or to detect an unwanted redun- 
dancy. Only an identifier that is unique to every single ob- 
ject can meet this requirement. However, the simple arrangement 
of the objects in a numerical order would not work, since by 
mistake the same object could be listed under different numbers 
without the means of recognizing the error. The only way to 
solve this problem is by introducing a key value that can only 
be applied in connection with the particular object it defines, 
like a social security number or a similar characteristic 
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attribute. We adopt this technique but leave the selection 
of the proper criterion up to the application programmer. 

However, it is considered advantageous always to define the 
first ' property_id ' of a class as the key element. This would 
allow the arrangement of the objects in a numerical or alpha- 
betical order with regard to their identifiers. 

Deletion and modification have one thing in common. The 
particular object must be retrieved first before the operation 
can be applied. This will be achieved in a similar way as for 
the 'selection' operator. The 'pv' set of the object in ques- 
tion is loaded into a set of registers and the appropriate 
class is identified. Then the ' pv ' set representing the first 
object of the class is loaded into a separate set of registers 
and checked for identity. As soon as a match occurs the search 
stops. In the case of a modification the up-dated 'pv' set 
will be stored in memory and the pointers are adapted to the 
new location. For a deletion operation the pointers are advanced 
and the "erased" object will be by-passed. If the indicated ob- 
ject cannot be found in the appropriate class, an error handling 
routine is activated and the state of the database will not 
be changed. 
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VII. CONCLUSIONS 



Interface standards that are precise, understandable and 
enforceable can provide a way to improve efforts toward porta- 
ble software. With the abstraction of a database, we not only 
extended AM by adding another basic resource to the processor 
and the visual display device, but also showed a way to reduce 
the database to its fundamental properties. Rather than being 
concerned with a specific data definition or query language, 
our abstraction of a database is intended to provide a uni- 
form, abstract, and functional interface to the computing system. 

By this concept the application programmer retains all the 
freedom he needs to actually implement the database resource 
in a way that fits his purpose best. And although it may turn 
out that the AM machine becomes even slower as the result of 
the additional data types we introduced, the specified axioms 
fully describe the operations in a precise, unambiguous and 
easily understandable manner, thus leaving no room for any 
different interpretation by the programmer. 

Based on the principle of resource abstraction, the AM 
specification intensively supports a strong typing such that 
objects of a given type can not take other values than the ones 
appropriate to the type, and no operations can legally be 
applied to an object which are not defined for its type. All 
these decisions naturally reduce efficiency, but this loss 
will be compensated by gains in clearness and accuracy. 
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It is difficult to foresee how much AM can be modified for 



efficiency without compromising the level of abstraction pre- 
sently achieved. To test for resource equivalence or to prove 
the correctness of implementations of resource specifications 
is a nontrivial matter, and this problem certainly will in- 
crease with every change attempted. So, for the near future, 
it seems that we have to pay the price for implementing in 
a strictly formal way, since no promising theory is yet known 
to reduce the large number of necessary function calls within 
the specif ication. 

Further basic resources that could be taken into consider- 
ation for a possible AM extension are a so-called mouse device 
with properties similar to the joy stick cursor, and a 
keyboard . 
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APPENDIX A 



A GRAMMAR FOR ALGEBRAIC SPECIFICATIONS 



abstraction : 

(abstraction spec) ? 



spec : 

(spechead | parmhead) specbody specend 

spechead : 

nameblk ' is ' 

parmhead: 

nameblk ' parm ' specbody 'is' 



specend : 

'end' specname ':' 



nameblk : 

'spec' specname 



specbody : 

extension? specblk 
extens ion : 

extendblk specblk 'end' 'extend' ';' 
extendblk : 

'extend' specnames 'with' 

specnames : 

specname 

| specnames ' , ' specname 



specblk : 

useblk 

| sortblk? opblk axiomblk? 



useblk : 

'use' specname '(' specname ') ' mapping? specblk 
' enduse ' 



mapping : 

'where ' eqivlist 

equivlist: 

equivalence ' ; ' 

| equivlist equivalence ';' 
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equivalence : 

sortname ' is ' sortname 
| opname ' is ' opname 

sortblk : 

'sort' sortnames 

sortnames : 

sortname ' ; ' 

| sortnames sortname ' ; ' 

opblk : 

primblk? dervblk? hiddenblk? 

primblk : 

'primitive' 'op' ops 

ops : 

op ' ; ' 

| ops op ' ; ' 

op : 

opname ';' arglist? '->' sortname 

arglis t : 

sortname 

| arglist ',' sortname 
dervblk : 

dervops dervdef 

dervops : 

'derived' 'op' ops 

dervdef : 

'derived' 'def' axioms 

hiddenblk : 

'hidden' 'op' ops 

axiomblk : 

'axiom' axioms 

axioms : 

axiom ' ; ' 

| axioms axiom ' ; ' 

axiom: 

conditional 

('for' varlist 'in' sortname)? termexpr '=' termexpr 
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termexpr : 

factor 

(multiplier? opname '(' factors ')' 



factors : 

factor 

| factors ' , ' factor 



factor : 

multiplier? opname ' ( ' ' ) ' 

| freevar 



varlist : 

freevar 

| varlist ' , ' freevar 
multiplier: 

' [' positive_number '] ' 
conditional : 

'if' termexpr meta_relop termexpr then else? 

meta_relop : 

1 = 1 
' I - ' 

then : 

'then' axioms 

else : 

'else' axioms 



' endif ' 
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APPENDIX B 



THE SPECIFICATION FOR AM (VERSION 3.0) 



replace ( ) 

"NUMINTENS" 

with 

"199" 



replace ( ) 

"DISPLAYSIZE" 

with 

"9999- 



replace (X, S) 

"equivrel (X,S) ; " 
with 

" X ( i , i ) = true ( ) ; 

X ( i , j ) = X ( j , i ) ; 

implies (and (X ( i , j ) ,X ( j , k) ), X ( i ,k) ) = true ( ) ; " 



replace (X, S) 

"reflexive (X, S ) ; " 
with 

" X ( i , i ) = true ( ) ; " 



replace (X , S ) 

" commut at i ve ( X , S ) ; " 
with 

" X ( i , j ) = X ( j , i ) ; " 



replace ( X , S ) 

" transitive (X , S) ; " 

with 

" implies (and (X ( i , j ) ,X ( j ,k) ), X ( i ,k) ) = true ( ) ; " 



replace (X, S) 

"associative (X, S) 
with 

"X(i,X( j ,k) ) = X(X(i, j) ,k) ; " 
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replace (X , S) 

"irreflexive (X,S) ; " 
with 

"X (i , i) = false ( ) ; " 



replace (X, S) 

"symmetric (X,S) 
with 

"implies ( X ( i , j ) ,X (j , i) ) = true ( ) ; " 



replace (X, S) 

"antisymmetric (X, S) ; " 
with 

"implies (and (X(i,j ) ,X(j , i) ), (i == j ) ) = true ( ) ; " 



replace ( S , T) 

"idopers (S ,T) ; " 
with 

"startT: ->• S; 
nextT:S -► S; 
prevT:S ->■ S; 
eqS : S , S -»• bool ; " 



replace ( S , T) 

"idaxioms (S ,T) ; " 
with 

"prevS ( startT () ) = undef; 
prevS (nextS ( i) ) = i; 
if i != startT () then 
nextS (prevS ( i) ) = i; 
endif ; 

equivrel ( eqS , S ) ; " 



replace ( S) 

"typingopers (S) ; " 
with 

"typeS: -*■ type; 
atomofS: val -*■ S; 
valof S : S -*■ val ; " 



replace (S ) 

" typingaxioms (S) ; " 
with 

"whattype (valof S ( t) ) = types () ; 
atomofS (valof S ( t) ) = t; 
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if whattype (v) = types ( ) 

then valof S (atomofS (v) ) = v; 
else atomofS (v) = undef; 
endif ; " 



replace ( S , T) 

"relop (S,T) ; " 
with 

"applyrop (ST ( ) , vl , v2) = valofbool (TS (atomofS (vl) , 
atomofS ( v2) ) ) ; " 



replace (S) 

"isops(S) ; " 
with 

"if whattype(v) = types () 

then applybop ( isS ( ) , V) = valofbool ( true ()) ; 
else applybop ( isS (), v) = valofbool (false ()) ; 
endif ; " 



replace (S , T) 

"stateaxioms (S ,T) 
with 

" fetchS (a , initam ( ) ) = undef; 
stores (fetchS (a, q) ,a ,q) = q; 
implies ( 

eqT (al , a2) , 

fetchS (al , stores (v,a2 ,q) ) = v 
) = true ( ) ; 
implies ( 

not (eqT (al ,a2) ) , 

fetchS (al , stores (v, a2 ,q) ) = fetch(al,q) 

) = true ( ) ; " 

replace /* database part */ 

"crpidset " 
with 

"pidsetlist .makelst" 



replace 

"unpidset " 
with 

"pidsetlist. unis t " 



replace 

"intpidset" 

with 

"pidsetlist . intis t" 
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replace 

"mempidset " 
with 

"pidsetlist .memblst " 



replace 

"crvalset " 
wi th 

" valsetlist. make 1st" 



replace 

"unvalset " 
with 

"valsetlist . unlst" 



replace 

"intvalset" 

with 

"valsetlist . intis t" 



replace 

"memvalset" 

with 

"valsetlist .memblst" 



replace 

"getid" 

with 

"proplist . firs 1 1st " 



replace 

"getvalset " 
with 

"proplist. restlst" 



replace 

"crprop" 

with 

"proplist . cat 1st" 

replace 

"crpropset" 

with 

"propsetlist .makenewlst" 
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replace 

"unpropset " 
with 

" props et list . unlst " 



replace 

" intpropset " 
with 

" props etl is t . in t 1st " 



replace 

"getidset " 
with 

"propsetlist .sofirstlst" 



replace 

"mempropset " 
with 

"propsetlist .memblst" 



replace 

"crpropval" 

with 

"pvallist. catlst" 



replace 

"getpid" 

with 

"pvallist .firstlst" 



replace 

"getval" 

with 

"pvallist. re stlst" 



replace 

"memprop" 

with 

"pvallist .memblst" 



replace 

"crpvalset " 
with 

"pval set list . makenewlst " 
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replace 

"unpvalset " 
with 

"pvalsetlist . unlst" 



replace 

"intpvalset" 

with 

"pvalsetlist . intis t" 



replace 

"mempvalset " 
with 

"pvalsetlist .memblst" 



replace 

"mempset " 
with 

"pvalsetlist .memblst" 



replace 

"getpidset " 
with 

"pvalsetlist. sof irstlst" 



replace 

"crobj " 
with 

"ob j list .makenewlst" 



replace 

" readob j " 
with 

"ob j list .makenewlst" 



replace 

"haspval" 

with 

"obj list .memblst " 



replace 

"getopidset " 
with 

"obj list. sofirstlst" 



replace 

"getoval " 
with 

"ob j list . getlst" 



replace 

" crclass " 
with 

"class list .makenewlst" 



replace 

"unclass " 
with 

"classlist. unlst" 



replace 

" intclass " 
with 

"classlist. intlst" 



replace 

"memclass " 
with 

"classlist .memblst" 



replace 

"subclass" 

with 

"classlist .memblst" 



replace 

"getcpidset " 
with 

"classlist.sofirstlst" 



replace 

" insob j" 
with 

" classlist. catlst" 



replace 

" delob j " 
with 

"classlist. deist" 
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replace 

"crdb" 

with 

"dblist .makenewlst " 



replace 

"memdb " 
with 

"dblist .memb 1st " 



replace 

"insclass " 
with 

"dblist. cat 1st " 



replace 

"delclass " 
with 

"dblist . deist" 



replace 

"retclass " 
with 

"dblist. in tlst" 



replace 

"retob j " 
with 

"dblist . retob j 1st " 



replace 

"getbdbidset " 
with 

"dblist . sofirs tlst " 



replace 

"modobj" 
with •» 

"dblist .modlst" /* database part */ 



157 



spec boolean 
is 

sort 

bool ; 
primitive 
op 

true: -* bool; 
false: -* bool; 
not: bool -> bool; 
and: bool, bool -> bool; 
derived 
op 

or: bool, bool -»■ bool; 
implies: bool, bool -► bool; 
derived 
def 

or(bl,b2) = not (and (not (bl) , not (b2) ) ); 

implies (bl ,b2) = not (and (bl , not (b2) ) ); 

axiom 

false() = not(true()); 
not (not (b) ) = b ; 
and ( true () ,b) = b; 

and ( false () ,b) = falseO; 
commutative (and , bool) ; 
end boolean; 



spec natural 
is 

extend 

boolean 

with 

sort 



nat ; 

primitive 

op 



zeronat 


: -> nat; 




/* 


zero * / 


prednat 


: nat -> 


nat ; 


/* 


predecessor */ 


succnat 


: nat •* 


nat ; 


/* 


successor */ 


sumnat : 


nat , nat 


-* nat ; 


/* 


addition */ 


subna t : 


nat , nat 


-*■ nat ; 


/* 


subtraction */ 


ml tnat : 


nat , nat 


-> nat ; 


/* 


multiplication */ 


divnat : 


nat ,nat 


-► nat; 


/* 


division */ 


> eqnat : 


nat , nat 


->■ bool; 


/* 


equal */ 


gtnat : 


nat , nat 


bool; 


/* 


greater than */ 


derived" 

op 










1 tnat : 


nat , nat 


-► bool; 


/* 


less than */ 


genat : 


nat , nat 


-> b oo 1 ; 


/* 


greater or equal */ 


lenat : 


nat , nat 


-*■ bool; 


/* 


less or equal */ 


nenat : 


nat , nat 


bool ; 


/* 


not equal */ 
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derived" 

def 



not (or (gtnat (n ,m) , eqnat (,n ,ra) ) ) ; 

not ( ltnat (n,m) ) ; 
not (gtnat (n,m) ) ; 
not ( eqnat (n ,m) ) ; 



ltnat ( n ,m) 
genat (n ,m) 
lenat ( n,m) 
nenat (n ,m) 
axiom 

prednat ( zeronat (.) ) = undef ; 
prednat (succnat (n) ) = n; 
succnat (prednat (n) ) = n; 
sumnat (n , zeronat () ) = n; 

sumnat ( n , succnat (m) ) = succnat (sumnat (n,m) ) ; 
subnat (n , zeronat () ) = n; 
if gtnat (n,m) = true ( ) 
then 

subnat (n , succnat (m) ) = prednat (subnat (n,m) ) 
else 

subnat ( n , succnat (m) ) = undef; 
endif ; 

mltnat (x, zeronat () ) = zeronatO ; 

ml tnat (x, succnat ( zeronat () ) ) = x; 

mltnat (x,y) = sumnat (x, mltnat (x, prednat (y) ) ); 

if y = zeronatO 

then 

divnat(x,y) = undef; 
else if ltnat(x,y) = true ( ) 
then 

divnat(x,y) = zeronatO; 
else 

divnat(x,y) = sumnat ( 
succnat ( zeronat ( ) ) , 
divnat ( subnat (x,y) ,y) 



) ; 

endif; 
endif ; 

eqnat(n,m) = eqnat(succnat(n) ,succnat(m) ) ; 
gtnat ( succnat ( n) , n) = true ( ) ; 
equivrel ( eqnat , nat) ; 
irreflexive ( gtnat , nat) ; 
irreflexive ( ltnat , nat ) ; 
transitive (gtnat , nat) ; 
transitive ( ltnat , nat) ; 
transitive (genat , nat) ; 
transitive ( lenat , nat ) ; 
antisymmetric (genat , nat) ; 
antisymmetric ( lenat , nat ) ; 
symmetric (nenat , nat) ; 
commutative ( sumnat , nat) ; 
commutative (mltnat , nat ) ; 
associative ( sumnat , nat) ; 
associative (mltnat , nat) ; 
end extend; 
end natural; 
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spec integer 
is 



extend 

boolean , 
nat 
with 

sort 
int ; 

primitive 

op 

zeroint: int; 

ntoi; nat -»• int; 
iton : int -»■ nat; 
absint: int ->■ int; 
predint: int -> int; 
succint: int -► int; 
sumint : int, int -*■ int; 
subint: int,int ■* int; 
mltint: int, int ■+ int; 
divint: int, int -> int; 
modint: int, int int; 
eqint: int, int -> bool; 
gtint: int, int -* bool; 
derived 
op 

ltint : int, int -> bool; 
geint: int, int bool; 
leint: int, int -* bool ; 
neint: int , int -*■ bool; 
derived 
def 



/* nat to int */ 
/* int to nat */ 
/* absolute value 



/* modulo */ 



not (or (gtint (n ,m 
not ( ltint (n ,m) ) 
not (gtint (n ,m) ) 
not (eqint (n ,m) ) 



ltint(n,m) = not (or (gtint (n ,m) , eqint (n ,m) 
geint (n ,m) 
leint (n ,m) 
neint (n , m) 
axiom 

predint ( succint (n) ) = n; 
succint ( predint (x) ) = x; 

ntoi ( zeronat ( ) ) = zerointO; 

ntoi ( succnat (n) ) = sumint ( succint ( zeroint ()) , 

ntoi (n) ) ; 

iton ( zeroint () ) = zeronat (); 

if ltint (x , zeroint () ) = true ( ) 
then 

iton(x) = undef; 
else 

iton (succint (x) ) = sumnat ( succnat ( zeronat) 

iton ( x) ) ; 

endif ; 



V 
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if ltint (x , zeroint ( ) ) = true (.} 
then 

absint(.x) = subint (zeroint () ,x) ; 
else 

absint(x) = x; 
endif; 

sumint (n , zeroint () ) = n; 

sumint (n, succint (m) ) = succint (sumint (n,m) ) ; 
subint (x , zeronat () ) = x; 

subint (x , succnat (y) ) = predint (subint (x ,y) ) ; 

mltint (x , zeroint () ) = zeroint (); 

mltint (x , succint ( zeroint () ) ) = x; 

mltint(x,y) = sumint (x ,ml tint (x , predint (y) )_ ); 

if y = zeroint () 

then 

divint(x,y) = undef; 

else if ltint ( absint ( x) , absint (y) ) = true() 
then 

divint(x,y) = zerointO; 
else if or( 
and ( 

gtint (x , zeroint ( ) ) , 
gtint (y , zeroint ( ) ) 

) , 

and ( 

ltint (x , zeroint () ) , 
ltint (y , zeroint ( ) ) 

) 

) = true ( ) 

then 

divint(x,y) = sumint( 
succint ( zeroint ( ) ) , 
divint (subint (x ,y) ,y) 

) ; 

else 

divint (x,y) = sumint ( 
predint ( zeroint ( ) ) , 
divint ( sumint (x ,y) ,y) 

) ; 

endif; 

endif; 

endif; 

if gtint (m, zeroint () ) = true ( ) 

then 

if ltint (n , zeroint () ) = true ( ) 
then 

modint(n,m) = modint ( sumint (n ,m) ,m) ; 
else 

modint(n,m) = subnat (n ,mltnat (m, divint ( n , m) ) ) 

endif; 
else 

modint (n,m) = undef; 
endif ; 
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eqint(x,y) = eqint ( succint (x) , succint (y) ) ); 

gtint ( succint (n) ,n) = true ( ) ; 
equivrel (eqint , int) ; 
irreflexive (gtint , int) ; 
irreflexive ( 1 ting , int) ; 
transitive (gtint , int) ; 
transit ive ( ltint , int ) ; 
transitive (geint , int) ; 
transitive ( leint , int) ; 
antisymmetric (geint , int ) ; 
antisymmetric (leint , int) ; 
symmetric (neint , int) ; 
commutative (sumint, int) ; 
commutative (mltint , int) ; 
associative ( sumint , int) ; 
associative (mltint , int) ; 
end extend; 
end integer; 



spec character 
is 

extend 

boolean 

with 

sort 



char ; 
primitive 
op 



A' , 
a ' , 




' Z ' : char ; 

' z ' : -v char; 



I ' , ' © ' 




* % ' 
t o r 


l /v i 

r 


'& 1 


f 1*1 

r 


' ' ( ' 

/ V A 


') ' : 


-> 


char 


r 


1 i 1 1 _ 1 

r ~ r ~ 


i ~ i 
/ / 


i i i 

r 


'{ 1 


, '} ' 


1 1 r » 

tit 


'] ’ : 


-V 


char 


It 1 It 1 

r 


i . i i . i 

t • / / 


i i 

t r r 


i i 

t • 


'< 1 


, ’> ' 


i 9 i 
r • r 




-V 


char 


1 1 II. 

1V2' 


char; 
, * 3 * , '4' 


r t 


'6' , 


' 7 ' 


, ' 8 1 


1 Q 1 

r ? t 


'O': 




char 



NUL 


char; 


SOH 


-*■ char; 


STX 


-> char; 


ETX 


-> char; 


EOT 


-*■ char; 


ENQ 


-> char; 


ACK 


-> char; 


BEL 


char; 


BS 




■* char; 


HT 




char; 


LF 




-> char; 


VT 




-> char; 


FF 




-»• char; 


CR 




char; 


SO 




-> char; 


SI 




char; 


DLE : 


: -► char; 
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DCl : -*■ char; 

DC2: -»■ char ; 

DC3 : -► char; 

DC 4 : ->• char; 

NAK: -»■ char; 

SYN : -»■ char; 

ETB : -»■ char; 

CAN: -*■ char; 

EM: -*■ char; 

SUB: ->■ char; 

ESC: -»■ char; 

FS : -»■ char; 

GS : -*■ char; 

RS : -»■ char; 

US: -»■ char; 

SP: -»■ char; 

DEL: -»■ char; 

eqchar: char, char -*• bool; 
gtchar: char, char -»■ bool; 
derived 
op 

ltchar 
gechar 
lechar 
nechar 
derived 
def 

ltchar 
gechar 
lechar 
nechar 
axiom 



char, char -»■ bool; 
char, char -*■ bool; 
char, char -»■ bool; 
char, char -*• bool; 



(n , m) 
(n,m) 
(n,m) 
( n , m) 



not (or (gtchar (n ,m) , eqchar (n ,m) ) ) 

not ( ltchar (n ,m) ) 
not ( gtchar ( n ,m) ) 
not ( eqchar ( n ,m) ) 



gtchar ( 'DEL 


1 1 ~ 
f 


') 


= trued 


gtchar ( ' ~ ' , 


'}') 


= 


true ( ) ; 


gtchar ( ' } ' , 


’1 ') 


= 


true ( ) ; 


gtchar ( ' | ' , 




= 


true ( ) ; 


gtchar ( ' { ' , 


'z') 


= 


true ( ) ; 


gtchar ( ' z ' , 


• • • / 


'a 


' ) = true 


gtchar ( ' a ' , 


' ') 


= 


true ( ) ; 


gtchar ( ' ' , 


' ') 


= 


true ( ) ; 


gtchar ( ' ' , 




= 


true ( ) ; 


gtchar ( ' ~ ' , 


'] ') 


= 


true ( ) ; 



gtchar ( ' ] 
gtchar ( ' ' , 



') 
' ) 



= true ( ) ; 
= true ( ) ; 



gtchar ( ' [ ' , 


' Z ' ) 


= 


true ( ) ; 


gtchar ( ' Z 1 , 


• • • / 


'A 1 


' ) = true 


gtchar ( ' A ' , 




= 


true ( ) ; 


gtchar ( ' @ ' , 


i ? ' ) 


= 


true ( ) ; 


gtchar ( ' ? ' , 


’> ' ) 


= 


trued ; 


gtchar ( ' > ' , 


'=') 


= 


true ( ) ; 


gtchar ( ' = ' , 


'< ') 


= 


true ( ) ; 


gtchar ( ' < ' , 


' ? ') 


= 


true ( ) ; 
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gtchar ( ' ; 1 , ' : ' ) 


= 


trued ; 


gtchar ( ' : ' , ' 9 ' ) 


= 


true ( ) ; 


gtchar ( ' 9 ' , . . . , 


'0 


' ) = true () ; 


gtchar ( ' 0 ' , ' / ' ) 


= 


true ( ) ; 


gtchar ('/','. 1 ) 


= 


true ( ) ; 


gtchar ( ' . ' , ' - ' ) 


- 


true() ; 


gtchar ('-',', 1 ) 


= 


true ( ) ; 


gtchar (',','+') 


= 


true ( ) ; 


gtchar ( '+','*') 


= 


true () ; 


gtchar ( , ') ') 


= 


true () ; 


gtchar ( ') ','(') 


= 


true ( ) ; 


gtchar ( ' (’,"’) 


= 


true ( ) ; 


gtchar ( ' ' ' , '&') 


= 


true ( ) ; 


gtchar ( , '%') 


= 


true ( ) ; 


gtchar ( '%','$') 


= 


true ( ) ; 


gtchar ('$' , '# ') 


= 


true ( ) ; 


gtchar ( ' # ' , '"' ) 


= 


true ( ) ; 


gtchar ( ' " ' , ' I ' ) 


= 


true ( ) ; 



gtchar ( ' ! ' , SP) = true ( ) ; 
gtchar (SP, US) = true ( ) ; 
gtchar (US , RS ) = true ( ) ; 
gtchar (RS ,GS) = true(); 
gtchar (GS ,FS) = true ( ) ; 
gtchar (FS , ESC) = true ( ) ; 
gtchar (ESC , SUB) = true ( ) ; 
gtchar (SUB , EM) = true ( ) ; 
gtchar (EM, CAN) = true(); 
gtchar (CAN , ETB) = true ( ) ; 
gtchar (ETB,SYN) = true ( ) ; 
gtchar ( SYN , NAK) = true ( ) ; 
gtchar (NAK,DC4) = true ( ) ; 
gtchar (DC4 , DC3) = true ( ) ; 
gtchar (DC3 , DC2 ) = true ( ) ; 
gtchar (DC2 ,DC1) = true ( ) ; 
gtchar (DCl , DLE) = trued ; 
gtchar (DLE , SI ) = true ( ) ; 
gtchar ( SI , SO) = true ( ) ; 
gtchar (SO,CR) = true ( ) ; 
gtchar (CR , FF) = true ( ) ; 
g tchar (FF , VT) = true ( ) ; 
gtchar (VT , LF) = true ( ) ; 
gtchar ( LF , HT) = true ( ) ; 
gtchar (HT,BS) = true ( ) ; 
gtchar (BS , BEL) = trued ; 
gtchar (BEL , ACK) = true ( ) ; 
gtchar (ACK , ENQ) = true ( ) ; 
gtchar (ENQ, EOT) = true ( ) ; 
gtchar (EOT, ETX) = trued; 
gtchar (ETX,STX) = trued ; 
gtchar (STX,SOH) = true ( ) ; 
gtchar (SOH ,NUL) = true ( ) ; 
equivrel (eqchar , char) ; 
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irref lexive (gtchar , char) ; 
irref lexive (ltchar , char) ; 
transitive (gtchar , char) ; 
transitive (ltchar, char) ; 
transitive (gechar , char) ; 
transitive ( lechar , char) ; 
antisymmetric (gechar , char) ; 
antisymmetric ( lechar , char) ; 
symmetric (nechar , char) ; 
end extend; 
end character; 



spec string 
parm 

extend 

boolean 

with 

sort 

lm; 

primitive 

op 



eqlm: 


lm, lm 




bool ; 


gtlm: 


lm, lm 


-> 


bool ; 


derived 








op 








ltlm: 


lm, lm 


-> 


bool ; 


gelm: 


lm, lm 


-> 


bool ; 


lelm: 


lm, lm 


-V 


bool ; 


nelm : 


lm, lm 


-> 


bool ; 


derived 









is 



def 

ltlm(n ,m) 
gelm (n ,m) 
lelm (n ,m) 
nelm(n,m) 
axiom 

equivrel ( eqlm, lm) ; 
irref lexive (gtlm , lm) ; 
irref lexive ( ltlm , lm) ; 
transitive (gtlm, lm) ; 
transitive ( ltlm, lm) ; 
transitive ( gelm , lm) ; 
transitive (lelm, lm) ; 
antisymmetric (gelm , lm) ; 
antisymmetric ( lelm , lm) ; 
symmetric ( nelm , lm) ; 
end extend ; 

extend 

natural 

boolean 



not (or (gtlm (n ,m) ,eqlm(n,m) 
not (ltlm (n ,m) ) ; 
not (gtlm (n,m) ) ; 
not (eqlm ( n , m) ) ; 
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with 

sort 
s tr ; 

primitive 

op 

nullstr: -*■ str; 
makes tr: lm -»■ str; 
lenstr: str -* nat; 
headstr: str lm; 
tailstr: str -»■ str; 
catstr: str, str -»■ str; 
eqstr: str, str -»■ bool; 
gtstr: str, str -*■ bool; 
derived 
op 

ltstr: str, str -> bool; 
gestr: str, str bool; 
lestr: str, str -*■ bool; 
nestr: str, str ■> bool; 
derived 
def 



/* null string */ 

/* make */ 

/* string length */ 
/* string head */ 

/* string tail */ 

/* concatenation */ 



not Cor (gtstr (n,m) , eqstr (n,m) ) ) 

not ( ltstr (n ,m) ) ; 
not (gtstr (n ,m) ) ; 
not ( eqstr (n ,m) ) ; 



ltstr (n,m) 
gestr (n ,m) 
lestr (n ,m) 
nestr (n,m) 
axiom 

lenstr (nulls tr) = zeronat(); 

lenstr (makestr ( 1) ) = succnat ( zeronat ( ) ) ; 

lenstr ( catstr ( si , s 2) ) = sumnat (lenstr ( si) 

lenstr ( s2) ) ; 



headstr (makestr (1) ) = 1; 

tailstr (makestr ( 1 ) ) = nullstr; 

headstr (catstr (makestr (1) , s) ) = 1; 

tailstr (catstr (makestr (1) , s2) ) = s2; 

headstr ( nullstr ) = undef; 

tailstr (nulls tr) = nullstr; 

catstr (catstr (si , s2) , s3) = catstr(sl, 

catstr ( s2 , s3) ) ; 
catstr (nullstr , s ) = cats tr ( s , nullstr ) = s; 
implies (eqlm ( 11 , 12) , eqstr (makes tr ( 11 ) , 

makestr(12)) ) = true ( ) ; 

implies (gtlm(ll, 12) , gtstr (makestr ( 11) , 

makestr(12)) ) = true(); 
gtnat ( lenstr (makes tr ( 1) ) , lens tr (nullstr) ) 

= true ( ) ; 

implies (gtnat ( lenstr ( si ) , lenstr ( s2) ) , 

gtstr ( si , s2) ) = true ( ) ; 
if lenstr(sl)! = zeronatO 
then 

gtnat ( lenstr ( catstr ( si , s2) , lenstr ( s 2) ) 

= true ( ) ; 
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else 

eqnat ( lens tr (catstr ( si , s2 ) , lens tr ( s2) ) 

= true (.) ; 

endif; 

equivrel (eqstr , str ) ; 
irref lexive (gtstr , str) ; 
irreflexive (ltstr,str) ; 
transitive (gtstr , str) ; 
transitive ( ltstr , str ) ; 
transitive (gestr , str ) ; 
transitive ( lestr , str ) ; 
antisymmetric (gestr , str ) ; 
antisymmetric ( lestr , str ) ; 
symmetric (nestr , str ) ; 
end extend; 
end string; 



spec str.chartype 
is 

extend 

ch aracter 
with 
use 

string (character) 
where 

char is lm; 
eqchar is eqlm; 
gtchar is gtlm; 
ltchar is ltlm; 
gechar is gelm; 
lechar is lelm; 
nechar is nelm; 
end extend; 
end str.chartype; 



spec intensity 
is 

extend 

boolean 

with 

sort 

intens ; 
primitive 
op 

minintens : 
maxintens : 
nullintens 
predintens 



/* display part */ 



• intens; 
- intens ; 
■+ intens 
intens -► 



/* 

/* 

/* 

intens ; 



minimum intensity 
maximum intensity 
null intensity */ 



V 

V 



167 



succintens : intens -*■ intens ; 
sumintens: intens , intens -> intens; 
subintens: intens , intens -> intens; 
eqintens: intens , intens ■> bool; 
gtintens : intens , intens -*■ bool; 
derived 
op 

ltintens: intens , intens -> bool; 
geintens : intens , intens -* bool; 
leintens: intens , intens -> bool; 
neintens: intens , intens ■> bool; 
derived 
def 

ltintens (n ,m) = not (or (gtintens (n ,m) , eqintens (n , m) ) ) 

geintens (n ,m) = not (ltintens (n,m) ) ; 
leintens (n ,m) = not (gtintens (n,m) ) ; 
neintens (n ,m) = not (eqintens (n,m) ) ; 

axiom 

predintens (minintens ( ) ) = undef; 

predintens (nullintens ( ) ) = undef; 

succintens (maxintens () ) = undef; 

succintens (nullintens () ) = undef; 

sumintens (i . nullintens () ) = undef; 

subintens ( i , nullintens () ) = undef; 

maxintens () = [NUMINTENS ] succintens (minintens () ) 

sumintens (i , minintens () ) = i; 

subintens ( i , minintens () ) = i; 

sumintens ( i , succintens ( j ) ) = succintens 

( sumintens ( i , j ) ) ; 

if gtintens ( i , j ) = true() 
then 

subintens ( i , succintens ( j ) ) = 

predintens ( subintens ( i , j ) ) ; 

else 

subintens ( i , succintens ( j ) ) = undef; 
endif ; 

eqintens ( i , j ) = eqintens (succintens (i) , 

succintens (j)); 

eqintens ( i , j ) = eqintens (predintens ( i) , 

predintens ( j ) ) ; 

eqintens ( i , succintens (predintens ( i) ) ) = true(); 
eqintens ( i , predintens ( succintens ( i) ) ) = true ( ) ; 

if or ( 

eqintens ( i , nullintens ( ) ) , 
eqintens*( j , nullintens () ) 

) = true() 
then 

gtintens ( i , j ) = undef; 
endif 

gtintens (succintens ( i) , i) = trued ; 
equivrel (eqintens , intens) ; 
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irref lexive (gtintens , intens) ; 
irref lexive ( ltintens , intens ) ; 
transitive (gtintens , intens ) ; 
transitive ( ltintens , intens ) ; 
transitive (geintens , intens ) ; 
transitive ( leintens , intens ) ; 
antisymmetric ( geintens , intens ) ; 
antisymmetric ( leintens , intens ) ; 
symmetric (neintens , intens) ; 
commutative (sumintens , intens) ; 
associative ( sumintens , intens ) ; 
end extend; 
end intensity; 



spec pointcolor 
is 



extend 

boolean 

intensity 

with 

sort 

color ; 
primitive 
op 

nullcolor: -* color; 
redcompnt : color -*■ intens; 
grncompnt : color -> intens; 
blucompnt: color •> intens; 
eqcolor: color, color -> bool; 
def color: intens , intens , intens 



/* null color */ 

/* red component */ 

/* green component */ 
/* blue component */ 
/* equal color */ 
color ; 

/* define color */ 



axiom 

redcompnt (nullcolor () ) = nullintens ( ) ; 
grncompnt ( nullcolor () ) = nullintens () ; 
blucompnt (nullcolor () ) = nullintens () ; 
if and( 
or ( 

or ( 

eq intens ( il , nullintens ( ) ) , 
eqintens ( i2 , nullintens ( ) ) 

) , 



eqintens ( i3 , nullintens ( ) ) 

) , 

or ( 



or ( 

not (eqintens ( il , nullintens () ) ), 

not (eqintens ( i2 , nullintens () ) ) 

) , 

not ( eqintens ( i3 , nullintens () ) ) 

) 

) = true ( ) 



169 



then 

defcolor (il , i2 , i3) ) = undef; 
else 

redcompnt (defcolor ( il , i2 , i3) ) = il; 
grncompnt (defcolor ( il , i2 , i3) ) = i2; 
blucompnt (defcolor (il , i2 , i3) ) = i3; 
endif ; 

eqcolor (cl ,c2) = and ( 

and ( 

eqintens ( redcompnt ( cl) , redcompnt (_c2) ) , 
eqintens (grncompnt (cl) , grncompnt (c2) ) 

) , 

eqintens (blucompnt (cl) ,blucompnt (c2) ) 

) ; 

equivrel (eqcolor , color) ; 
end extend; 
end pointcolor; 



spec point 
is 

extend 

boolean , 
natural , 
integer 
with 

sort 
pnt ; 

primitive 
op 

xcord: pnt int; 
ycord: pnt ■+ int; 
locpnt : int, int -»■ pnt; 
eqpnt : pnt, pnt -* bool; 
gtpnt: pnt, pnt -> bool; 
ltpnt: pnt, pnt bool; 
gepnt: pnt, pnt -*■ bool; 

or right inline or above 
inline */ 

lepnt : pnt, pnt -> bool; /* left & below, 

or left inline or below 
inline */ 

offsetpnt: int, int, pnt -+ pnt; /* point offset */ 
axiom 

xcord ( locpnt (il , i2) ) = il; 
ycord ( locpnt ( il , i2 ) ) = i2 ; 
eqpnt (pi, p2) = and ( 

eqint (xcord (pi) ,xcord(p2) ) , 
eqint (ycord (pi) ,ycord(p2)) 

) ; 



/* x coordinate */ 

/* y coordinate */ 

/* point location */ 
/* equal point */ 

/* right & above */ 
/* left & below */ 

/* right & above. 
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gtpnt(pl,p2) = and ( 

gtint (xcord (pi) ,xcord(p2) ) , 
gtint (ycord (pi ) ,ycord(p2) ) 

) ? 

ltpnt (pi ,p2) = and ( 

ltint (xcord (pi) , xcord (p2) ) , 
ltint (vcord (pi) ,ycord(p2) ) 

) ; 

gepnt(pl,p2) = and ( 
or ( 

gtint (xcord (pi) , xcord (p2) ) , 
eqint (xcord (pi) ,xcord(p2) ) 

) , 

or ( 

gtint (ycord (pi) ,ycord(p2) ) , 
eqint (ycord (pi) ,ycord(p2) ) 

) 

) ; 

lepnt(pl,p2) = and( 
or ( 

ltint (xcord (pi) ,xcord(p2) ) , 
eqint (xcord ( pi) , xcord (p2) ) 

) , 

or ( 

ltint (ycord (pi) , ycord (p2) ) , 
ecrint (ycord (pi) ,ycord(p2) ) 

) 

) ; 

if x = zerointC) 
then 

xcord (offsetpnt (x,y,p) ) = xcord(p); 
else if gtint (x, zeroint () ) = true ( ) 
then 

xcord (of fsetpnt ( x , y , p) ) = succint (xcord 
(of fsetpnt (predint ( x) , y , p) ) ) 

else 

xcord (of fsetpnt ( x , y , p) ) = predint (xcord 
(offsetpnt (succint (x) ,y,p) ) ) 

endif ; 
endif ; 

if v = zeroint () 
then 

ycord (of fsetpnt ( x ,y , p) ) = ycord(p2); 

else if gtint (y , zerint () ) = true ( ) 
then 

ycord (of fsetpnt ( x ,y , p) ) = succint (ycord 
(off setpnt (x, predint (y) ,p) ) ) 

else 

ycord (of fsetpnt (x,y ,p) ) = predint (ycord 

(off setpnt (x , succint (y) , p) ) ) 

endif ; 
endif ; 
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equivrel ( eqpnt , pnt) ; 
ref lexive (gepnt , pnt) ; 
ref lexive ( lepnt , pnt) ; 
irreflexive (gtpnt ,pnt) ; 
irreflexive(ltpnt,pnt) ; 
transitive (gtpnt , pnt) ; 
transitive ( ltpnt , pnt) ; 
transitive (gepnt , pnt) ; 
transitive ( lepnt , pnt) ; 
end extend; 
end point; 



spec rectangle 
is 

extend 

boolean , 
integer , 
point 
with 

sort 

ret ; 

primitve 

op 



origin: ret -* pnt; 


/* lower left 


corner */ 




corner : ret -* pnt ; 


/* upper right 


corner */ 




xdimret : ret -> int; 


/* x dimension */ 


ydimret: ret -> int; 


/* y dimension */ 


area: pnt, pnt ->■ ret; 


/* define ret */ 


inret: pnt, ret -* bool; 


/* pnt inside ret 


test */ 




disjrct: ret, ret -> bool; 


/* disjoint rets */ 


intsetret: ret, ret ret; 


/* ret intersection 


putret : pnt , ret -»■ ret; 


/* put ret at 


location * 


7 


shiftret: int, int, ret ■+ ret; 


/* shift ret */ 


axiom 




if ltint (xcord (p2) , xcord (pi) ) 
then 


= true ( ) 


xcord (origin (area (pi ,p2) ) ) 


= xcord (p2) ; 


else 




xcord (origin ( area ( pi , p2 ) ) ) = 

endif ; 


xcord (pi) ; 


if ltint (ycord (p2) ,ycord (pi) ) 
then 


= true ( ) 


ycord (origin (area (pi ,p2) ) ) 


= ycord (p2) ; 


else 




ycord (origin (area (pi ,p2) ) ) 


= ycord (pi) ; 


endif ; 





V 
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= trueQ 



if gtint (xcord (pi) ,xcord (p2) ) 
then 

xcord (corner (area (pi , p2) ) ) 

else 

xcord (corner (area (pi , p2) ) ) 

endif ; 

if gtint (ycord (pi) ,ycord (p2) ). 
then 

ycord (corner (area(pl,p2) ) ) 
else 

ycord (corner (area (pi ,p2) ) ) 

endif ; 

inrct(p,r) = and( 

gepnt (p , origin (r) ) , 
lepnt (p , corner ( r) ) 

) ; 

dis jrct ( rl , r2) = 
not (or (. 
or ( 

inrct (origin (r2) ,rl) , 
inrct (corner (r2) ,rl) 

) , 

or ( 



= xcord (pi) 
= xcord (p2) 
= true Q 
= ycord (pi) 
= ycord(p2) 



inrct ( 

locpnt ( xcord (origin ( r2) ) , 

ycord (corner ( r2) ) ) , 

rl 



) , 

inrct (. 

locpnt (xcord (corner (r2) ) , 

ycord (oricrin ( r2) ) ), 

rl 



) 



) ) ; 

if dis jrct (rl , r2) = trued 

then 

intsctrct ( rl , r2) = undef; 
else 

inrct ( p , intsctrct (rl , r2) = and ( 
inrct (p, rl) , 
inrct (p , r2) 

) ; 

endif ; 

shif tret (x , y , r) = area( 

of fsetpnt (x ,y , origin (r) ) , 
of fsetpnt (x , y , corner ( r) ) 

) ; 

putrct(p,r) = area( 

P/ 

of fsetpnt ( xdimret (r) ,ydimrct(r) ,p) 

) ; 
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xdimrct(r) = subint( 
xcord (origin (r) ) , 
xcord (corner ( r) ) 

) ; 

ydimrct(r) = subint( 
ycord (origin (r) ) , 
ycord (corner (r) ) 

) ; 

end extend; 
end rectangle; 



spec imageform 
is 



extend 

boolean , 
pointcolor , 
point , 
rectangle 
with 

sort 

form; 

primitive 

op 

initform: ret -*■ form; 
farea: form -> ret; 



/* initialize form */ 
/* ret area of 



form */ 

getcolor: pnt, form -»■ color; /* get pnt color */ 
filiform: color, form -* color; /* fill form */ 
setcolor: pnt , color , form ■+■ form; 

/* set pnt color */ 



* invform - inverse form 

* given color A, color B, form F 

* map F foreground colors to A 

* map F background to B 

* / 



invform: color , color , form -*■ form; 
axiom 

farea(initform(r) ) = r; 

getcolor (p , initform (r) ) = nullcolorO; 

if inret (p , farea ( f) ) = true ( ) 

then getcolor (p , setcolor (p , c , f) ) = c; 
else getcolor (p , f) = nullcolorO; 
end if ; 

if inret (p , farea ( f) ) = true ( ) then 
getcolor (p , filiform (c , f) ) = c; 
endif ; 

if inret (p , farea ( f) ) = falseO then 
setcolor ( p , c , f) = undef; 
endif ; 
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if inrct ( p , f area ( f ) ) = true ( ) then 
if getcolor (p , f ) = nullcolorQ 
then 

getcolor (p , invform ( cl , c2 , f) ) = c2 ; 
else 

getcolor (p , invform (cl , c2 , f) ) = cl; 

endif ; 
endif ; 
end extend; 
end image form; 



spec iconfont 
is 

extend 

boolean , 
natural , 
pointcolor , 
rectangle , 
imageform, 
pntblktrans 
with 

sort 

font ; 
primitive 
op 



initfont 


: ret -► font; 




/* 


initialize font 


rctfont : 


font -»■ ret; 




/* 


ret of font 




icons 


V 






lenfont : 


font -> nat; 




/* 


number of icons 




in font */ 






spmap: rct,pnt -* pnt ; 




/* 


map spot (font 




loc) 


to pnt */ 


psmap: ret, pnt ■+ pnt; 




/* 


map pnt to spot 




( font 


loc) 


V 




infont : 


nat, font bool; 




/* 


for given index. 




does 


font 


have 


i icon */ 


delfont : 


nat , font -> font; 




/* 


delete icon 




from 


font 


*/ 




getfont : 


form, nat, font -»■ 


font ; 


/* 


put icon into 




font 


V 






offsetfont: int , int , font , 


pnt -> 


pnt 





/* offset in 

multiples of font rets */ 



axiom 

rctfont ( initfont (r) ) = r; 

lenfont ( initfont (r ) ) = zeronat ( ) ; 
spmap(r,p) = loepnt ( 

mltint (xcord (p) ,xdimrct (r) ) , 
ml tint (ycord (p) , ydimret (r ) ) 

) ; 
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psmap(r,p) = locpnt ( 

divint (xcord (p) ,xdimrct(r)) , 
divint (ycord (p) ,ydimrct(r) ) 

) ; 

infont ( id , initfont (r) ) = false (); 
infont ( id , delfont ( id , ft) ) = false(); 

infont ( id , setfont ( f , id , f t) ) = true ( ) ; 
if and ( 

eqint (xdimrct ( rctfont ( ft) ), xdimrct (farea ( f). ) ) , 

eqint (ydimrct ( rctfont ( ft ) ) , ydimrct ( farea (f) ) ) 

) = falseO 



then 

setfont (f , id , ft) = undef; 
endif ; 

if infont (id , ft ) = true ( ) 

then 

lenfont ( setfont ( f , id , ft ) ) = lenfont (ft); 
else 

lenfont (setfont ( f , id , ft ) ) = succnat ( lenfont ( ft ) ) 
endif; 

if infont ( id , ft) = true (.) 
then 

lenfont (delfont ( id , ft ) ) = prednat (lenfont ( ft )) ; 
else 

lenfont (delfont (id , ft) ) = lenfont(ft); 
endif; 

if infont ( id , ft ) = false() then 
getfont ( id , f t) = undef; 
endif; 

rctfont(ft) = farea (getfont (id , ft) ) ; 
getfont ( id , setfont ( f , id , ft ) ) = f; 

getfont (id , setfont (a , id , setfont (b , id , ft) ) ) = a; 

of f setfont (x , y , ft , p) = locpnt( 

sumint (xcord (p) , ml tint (x , xdimrct (rctfont ( ft) ) ) ) 

sumint (ycord (p) , ml tint (y , ydimrct (rctfont ( ft) ) ) ) 



end extend; 
end iconfont; 



I 



spec pntblktrans 
is 

extend 

natural , 
integer , 
point , 
rectangle , 
form 
with 

sort 

ptblt ; 
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primitive 



initptblt: -* ptblt; 


/* 


initialize ptblt */ 


getsret : 


ptblt -*■ ret; 


/* 


get 


source ret */ 


getdret : 


ptblt -* ret; 

ret */ 


/* 


get 


destination 


getcrct : 


ptblt ■+ ret; 


/* 


get 


clipping ret */ 


getrule : 


ptblt -* nat; 


/* 


get 


copy rule */ 


setsret : 


ret, ptblt -> ptblt; 


/* 


set 


source ret */ 


setdret : 


ret, ptblt -> ptblt; 

ret */ 


/* 


set 


destination 


setcrct : 


ret, ptblt -* ptblt; 


/* 


set 


clipping ret */ 


setrule : 


nat, ptblt ptblt; 


/* 


set 


copy rule */ 



/**************************************** 



* copyblt - form copy operation: 

* given source , mask destination forms ; 

* call cpyrecur with origin of wksrct 

* ptblt controls operation; 

V 

copyblt: ptblt , form, form , form -*• form; 

/ • k’k-k-k-k'k'k’k'k'k'k'k-k'k'k’k'k'k-k'k'k'kic'k'k'k'k'k'k'k'k'k'k'k'k-k'k-k'k'k 

* drawline - draws line between two pnts : 

* given start pnt , stop pnt, brush, destination 
mask ; 

* calls recursive h/v drawloop depending on 
slope of line 

* drawloop constructs line using repeated 

* calls to copyblt using source form as a 
brush 

V 

drawline: pnt , pnt , ptblt , form , form , form -> form; 

/**************************************** 

* copyfont - copy icon from font to a given 
point in the dest form 

* the source and dest ret in ptblt are 
automatically set 

V 

copyfont: pnt , ptblt , nat , font , form , form -* form; 

* inveopyfont - same as copyfont bit with 
inverse coloring on the 

* the font form source. 

*/ 

inveopyfont : color , color , pnt , ptblt , nat , font , form , 
form -»■ form; 

hidden 

op 

/********************•******************** 

* wksrct - working source ret 

* intersection of source form farea 

* and the ptblt source ret 
*/ 
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wksrct: form,ptblt -* ret; 

/**************************************** 

* wkdret - working destination ret 

* intersection of destination form farea 

* and the ptblt destination ret 
*/ 

wkdret: form, ptblt -»■ ret; 

/**************************************** 
modpnt - pnt modulo (2D modulo).: 
given pnt P, form F 
if P in F 
then P 

else (wrap P around into F) 
reduce coord of P 
by dim of F 
until P in F 



* 

* 

* 

* 

* 

* 

* 

: k 

V 



modpnt: pnt, form -*■ pnt; 

/**************************************** 

* getmcolor - applies the masking rules 

* given pnt P, source S, dest D, mask M, 

ptblt B 

returns color MS (masked source color) 
based on: 

masking policy 
S color @ P 
M color @ modpnt of 

matchpnt of P,S,D,B 



* 

* 

* 

* 

* 

* 

V 



getmcolor: pnt , ptblt , form, form, form color; 

/**************************************** 
* 



* 

* 

* 

* 

* 

* 

* 

V 



nextpnt - given pnt P, returns next pnt 
in wksrct 

based on sequential ordering imposed on ret 
start at origin 
if right neighbor of P in ret 

then return right neighbor of P 
else 

move left to ret boundary 
return pnt above 



nextpnt: pnt , ptblt , form 

/ 

* 



pnt ; 



**************************************** 
matchpnt - find corresponding pnt in dest 



* 

* 

* 

* 

* 

* 

*/ 

matchpnt : 



given pnt P, source S, dest D, ptblt B 
returns pnt that is offset XY from the 
origin of the wkdret 
where XY is the offset from the 
origin of the wksrct 
that equals P 



pnt , ptblt , form , form pnt; 
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/***************************************** 

* copypnt - set color at pnt in dest 

* given pnt P, source S, dest D, mask M, 

ptblt B 

* set color 0 matchpnt of P,S,D,B 

* based on: 

* B copy rule 

* MS color from getmcoloir of P,S,M 

* D color 0 matchpnt of P,S,D,B 

*/ 

copypnt : pnt , ptblt , form, form, form form; 

/***************************************** 

* cpyrecur - recursive function of copybit 

* given pnt P 

* if P in wksrct 

* then 

* call copypnt with P 

* call cpyrecur with nextpnt of P 

* else 

* stop recursion 

V 

cpyrecur: pnt , ptblt , form, form, form form; 

/***************************************** 



* hdrawloop - recursive function of drawline 

* used when absolute value of slope is < 45 

degrees 

* walks line one horizontal point at a time 

* moving vertically as required, 

* at each step: 

* sets ptblt destination ret 

* calls copybit 
*/ 

hdrawloop : nat , int , int , int , int , int , form, 

form, ptblt -> form; 

/***************************************** 

* vdrawloop - recursive function of drawline 

* used when absolute value of slope is >= 45 

degrees 

* walks line one vertical point at a time 

* moving horizontally as required 

* at each step: 

* sets ptblt destination ret 

* calls copybit 

V 

vdrawloop : nat , int , int , int , int , int , form, 

form, ptblt -> form; 



axiom 

gets ret ( ini cptblt () ) = area ( 

loepnt ( zeroint ( ) , zeroint ( ) ) , 
loepnt ( zeroint ( ) , zeroint ( ) ) 

) ; 



# 
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getdrct ( initptblt ( ) ) = area( 

locpnt ( zeroint ( ) ,zeroint() ) , 
locpnt ( zeroint ( ) , zeroint ( ) ) 

) ; 

getcrct ( initptblt () ) = area ( ’ 

locpnt ( zeroint ( ) , zeroint () ) , 
locpnt ( zeroint ( ) , zeroint ( ) ) 

) ; 

getrule ( initptblt () ) = zeronat () ; 

getsrct (setsrct (r ,pb) ) = r; 
getdrct (setdrct (r, pb) ) = r; 
getcrct (setcrct ( r , pb) ) = r; 
getrule ( setrule (n , pb) ) = n; 

wksrct(f,pb) = intsctrct (farea (f) , getsrct (pb) ) ; 
wkdrct(f,pb) = intsctrct ( farea ( f) , getdrct (pb) ) ; 
modpnt(p,f) = offsetpnt( 

modint (xcord (p) ,xdimrct (farea(f) ) ) , 

modint (ycord (p) , ydimrct ( farea ( f) ) ) , 

origin ( farea ( f) ) 

) ; 

^ \ k*************************************** 

* matchpnt 

* p: pnt in source 

* pb: ptblt 

* s: source 

* d: dest 

***************************************** y 
matchpnt (p ,pb , s ,d) = offsetpnt( 

subint ( 

xcord (p) , 

xcord (origin (wksrct ( s , pb ) ) ) 

) , 

subint ( 

ycord (p) , 

ycord (origin (wksrct ( s , pb) ) ) 

) , 

origin (wkdrct ( d , pb) ) 

) ; 

y/**************************************** 

*getmcolor 

* p: pnt in source 

* pb : ptblt 

* s : source 

* m: mask 

* d: destination 

**************************************** / 
if or ( 

eqcolor (getcolor (p , s) ,nullcolor() ) , 
eqcolor ( 

getcolor (modpnt (matchpnt (p , pb , s , d) ,m) ,m) , 
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nullcolor ( ) 



) 

) = true() 

then 

getmcolor(p,pb,s,m,d) = getcolor (p , s) ; 
else 

getmcolor (p ,pb , s ,m,d) = getcolor (modpnt 
(matchpnt (p ,pb , s , d) ,m) ,m) ; 

endif; 

/*************************.*************** 

* nextpnt 

* p: pnt in source 

* pb : ptblt 

* s : source 

*****************************************/ 
if ltint( 

xcord (p) , 

xcord (corner (wksrct ( s , pb) ) ) 

) - true ( ) 

then 

nextpnt (p ,pb , s) = locpnt( 
succint (xcord (p) ) , 
ycord (p) 

) ; 

else 

nextpnt (p , pb , s) = locpnt( 

xcord (origin (wksrct (s , pb) ) ), 

succint (ycord (p) ) 

) ; 

endif; 

y'****^*********************************** 

* copypnt 

* p: pnt in source 

* pt: ptblt 

* s : source 

* m: mask 

* d: destination 

* ★a-**************************************/ 
if inrct ( 

matchpnt (p , pb , s , d) 
intsctrct ( 

wkdrct (d ,pb) , 
getcrct (pb) 

) 

) = true() 
then 

if getrule(pb) = zeronat() 
then 

copypnt (p ,pb , s ,m,d) = d; 

else if getrule(pb) = [1 ] succnat ( zeronat ( ) ) 
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then 

if and( 

not ( eqcolor (getmcolor (p , pb , s ,m, d) , 
nullcolor ( ) ) ) , 

not (eqcolor ( 
getcolor ( 

matchpnt (p,pb , s ,d) , 
d 

) , 

nullcolor ( ) 

) ) 

) = true() 
then 

copypnt (p,pb , s ,m,d) = setcolor( 

matchpnt ( p , pb , s , d ) , 
getmcolor (p,pb , s ,m,d) , 
d 

) ; 

else 

copypnt (p,pb , s ,m,d) = d; 
end if ; 

else if getrule(pb) = [ 2 ] succnat ( zeronat () ) 
then 

if and ( 

not ( eqcolor (getmcolor (p , pb , s ,m, d) , 
nullcolor ( ) ) ) , 

eqcolor ( 

getcolor ( 

matchpnt (p,pb ,s ,d) , 
d 

) , 

nullcolor ( ) 

) 

) = true ( ) 
then 

copypnt (p ,pb , s ,m,d) = setcolor ( 
matchpnt (p,pb , s ,d) , 
getmcolor (p , pb , s ,m , d) , 
d 

) ; 

else 

copypnt (p,pb,s,m,d) = d; 
endif ; 

else if getrule(pb) = [ 3 ] succnat ( zeronat () ) 
then 

if getmcolor ( p , pb , s ,m , d) != nullcolorO 
then 

setcolor ( 

matchpnt ( p , pb , s , d ) , 
getmcolor (p,pb , s ,m,d) , 
d 
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else 

c °pypnt (p , pb , s ,m , d) = d; 
endif ; 

else if getrule(pb) = [ 4] succnat ( zeronat () ) 
then * 

if and( 

eqcolor (getmcolor (p , pb , s ,m, d) , 
nullcolor ( ) ) , 
not ( eqcolor ( 
getcolor ( 

matchpnt (p,pb , s ,d) , 
d 

) , 

nullcolor ( ) 

) ) 

) = true() 
then 

copypnt (p , pb , s ,m, d) = setcolor ( 
matchpnt (p , pb , s , d) , 
nullcolor ( ) , 
d 

) ; 

endif ; 

else if getrule(pb) = [ 5 ] succnat ( zeronat () ) 

then 

if getcolor ( 

matchpnt (p, pb , s , d) , 
d 

) ) ! = nullcolor ( ) 

then 

copypnt (p , pb , s ,m , d) = setcolor( 
matchpnt (p , pb , s , d) , 
getmcolor (p , pb , s ,m, d) , 
d 

) ; 

else 

copypnt (p,pb , s ,m, d) = d; 
endif ; 

else if getrule(pb) = [ 6] succnat ( zeronat () ) 
then 

if and( 
or ( 

eqcolor (getmcolor ( p , pb , s ,m , d) , 
nullcolor ( ) ) , 
not (eqcolor ( 
getcolor ( 

matchpnt ( p , pb , s , d ) , 
d 

) , 

nullcolor ( ) 

) ) 
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or ( 

not (eqcolor (getmcolor Cp, pb , s ,m, d) , 
nullcolor (,) ) ) ) , 

eqcolor ( 

* getcolor( 

matchpn t ( p , pb , s , d ) , 
d 

) , 

nullcolor ( ) 

) 

) 

) = true ( ) 
then 

copypnt (p,pb ,s ,m,d) = setcolor( 
matchpnt Cp , pb , s , d) , 
getmcolor (p ,pb , s ,m,d) , 
d 

) ; 

else 

copypnt Cp , pb , s ,m , d) = d; 
endif ; 

else if getrule(pb) = [ 7 ] succnat ( zeronat ( ) ) 
then 

if or ( 

not (eqcolor (getmcolor (p , pb , s , m, d) , 
nullcolor ( ) ) ) , 

not (eqcolor ( 
getcolor ( 

matchpnt (p,pb , s ,d) , 
d 

) , 

nullcolor ( ) 

) ) 

) = true ( ) 
then 

copypnt (p , pb , sm , d ) = setcolor ( 
matchpnt (p ,pb , s , d) , 
getmcolor (p , pb , s ,m, d) , 
d 

) ; 

else 

copypnt (p , pb , s ,m , d) = d; 

else 

copypnt (p , pb , s ,m , d) = d; 
endif; 
endif ; 
endif ; 
endif ; 
endif ; 
endif ; 
endif; 
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endif ; 
end if ; 
endif ; 

/**************************************** 

* cpyrecur 

* p: pnt in source 

* pb : ptblt 

* s: source 

* m: mask 

* d: destination 

**************************************** y 
if inrct (p ,wksrct ( s , pb) ) = true C) 
then 

/* copy pnt and continue */ 
cpyrecur (p , pb , s ,m, d) = cpyrecur ( 
nextpnt (p , pb , s) , 
pb 
s , 
m, 

copypnt (p , pb , s ,m, d) , 

) ; 

else 

/* all source pnts visited */ 
cpyrecur (p , pb , s , m, d) = d; 
endif ; 

/'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k 

* copyblt 

* pb : ptblt 

* s: source 

* m: mask 

* d: destination 

**************************************** 
if or ( 

disjrct (farea (s) , gets ret (pb) ) , 
dis j ret (farea (d) , getdret (pb) ) 

) = true ( ) 

then 

copyblt (pb , s ,m,d) = d; 

else 

copyblt (pb , s ,m , d) = 
cpyrecur ( 

origin (wksrct ( s , pb) ) , 

pb 

s , 

m, 

d, 

) ; 

endif ; 

/*************************************** 

* hdrawloop 

* n: dist to go (major axis) 
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* p: minor axis move counter (vertical) 

* dx : xDelta sign 

* dy : yDelta sign 

* px: yDelta abs 

* py: xDelta abs 

* s : source form 

* d: dest form 

* m: mask form 

* pb : ptblt 

/* is it the last step? */ 
if n = succnat ( zeronat () ) 
then 

/* time to move in minor direction? */ 
if ltint ( subint (p , px) , zeroint () ) = true ( ) 
then 

/* move minor */ 

hdrawloop ( n , p , dx , dy , px , py , s , d , m , pb = 
copyblt ( 

setdrct (shiftrct (dx , dy , getdrct (pb) ) ,pb) 

s, 

m, 

d, 

) ; 

else 

/* move major */ 

hdrawloop ( n , p ,dx , dy , px ,py , s , d ,m , pb) = 
copyblt ( 

setdrct ( shiftrct (dx , zeroint ( ) , 
getdrct (pb) ) ,pb) 
s , 
m, 
d, 

) ; 

endif ; 

else if ltint (subint (p ,px) , zeroint () ) = true ( ) 
then 

/* move minor and continue */ 
hdrawloop ( n , p , dx , dy , px , py , s , d , m , pb ) = 

hdrawloop ( 

/* reduce distance to go */ 
subnat ( n , succnat ( zeronat ( ) ) , 

/* reset counter for next minor move */ 
sumint ( subint (p , px) ,py) , 

dx , 

dy , 
px, 

PY/ 
s , 

/* move minor and major then copy brush */ 
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# 



copyblt ( 

setdrct ( shif tret (dx , dy , getdret (pb) ) , pb ) 
s , 
m, 
d, 

) , 



m, 

setdrct ( shif tret (dx , dy , getdret (pb ) ) , pb ) 

). ; 
else 

/* move major and continue */ 
hdrawloop ( n , p , dx , dy , px , py , s , d , m , pb ) = 
hdrawloop ( 

/* reduce dist to go */ 
subnat (n , succnat ( zeronat ( ) ) , 

/* reduce count till next minor move */ 
subint (p , px) , 

dx , 

dy , 
px, 

PY > 

s, 

/* move major then copy brush */ 
copyblt ( 

setdrct ( shiftret (dx , zeroint ( ) , 
getdret (pb) ) ,pb) 
s, 
m, 
d, 

) , 



m, 

setdrct ( shif tret ( dx , zeroint () , getdret (pb ) ) , 
pb) 

) ; 

endif ; 
endif ; 

y/**************************************** 

* vdrawloop 

* n: dist to go (major axis) 

* p: minor axis move counter (horizontal) 



* 


dx : 


xDelta 


sign 


* 


dy : 


yDel ta 


sign 


* 


px : 


yDelta 


abs 


* 


py : 


xDelta 


abs 


* 


s : 


source 


form 



* d: dest form 

* m: mask form 

* pb : ptblt 

*****************************************/ 
/* is it the last step? */ 
if n = succnat ( zeronat () ) 
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then 

/* last step */ 

if ltint ( subint ( p , py) , zeroint (.) ) = true() 
then 

/* move minor */ 

vdr awloop ( n , p , dx , dy , px , py , s , d , m , pb ) = 

copyblt ( 

setdrct (shiftrct (dx,dy, getdrct (pb) ) , pb) 
s , 
m, 
d, 

) ; 

else 

/* move major */ 

vdr awloop (n , p , dx , dy ,pz , py , s , d ,m , pb) = 
copyblt (. 

setdrct ( shiftrct ( zeroint ( ) ,dy, 
getdrct (pb) ) ,pb) 
s, 
m, 
d, 

) ; 

endif ; 

else if ltint (subint (p,py) ,aeroint () ) = true ( ) 
then 

/* move minor and continue walk */ 
vdrawloop (n , p , dx , dy , px , py , s , d ,m , pb) = 

vdrawloop ( 

/* reduce dist to go */ 
subnat (n , succnat ( zeronat ( ) ) ), 

/* set counter for next minor move */ 
sumint ( subint (p , py) ,px) , 

dx , 

dy, 
px, 

py ' 

S , 

/* move minor and major then copy brush */ 
copyblt ( 

setdrct ( shiftrct ( dx , dy , getdrct (pb ) ) , pb ) 
s , 
m, 
d, 

) , 

m, _ 

setdrct ( shiftrct ( dx , dy , getdrct (pb) ) ,pb) 

) ; 

else 

/* move major and continue walk */ 
vdrawloop(n,p,dx,dy,px,py ,s ,d,m,pb) = 

vdrawloop ( 
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/* reduce dist to go */ 
subnat ( n , succnat ( zeronat C) ) ), 

/* reduce count till minor move */ 
subint (p,py) , 

dx , 

dy , 

px, 

py> 

S, 

/* move major and copy brush */ 
copyblt (. 

setdrct ( shif tret ( zeroint Q , dy , 
getdrct(pb) ) ,pb) 
s , 
m, 
d, 

) , 

m, 

setdrct ( shiftret ( zeroint ( ) , dy , getdret ( pb) ) , 
pb) 

) ; 

endif ; 
endif ; 

/**************************************** 

* drawline 

* pi: start pnt 

* p2: end pnt 

* pb : ptblk 

* s : brush form 

* m: mask form 

* d: dest form 

***************************************** 
if and( 

subint (ycord (p2 ) ,ycord(pl) ) , 
subint (xcord (p2) ,xcord(pl) ) 

) = true ( ) 
then 

/* line is a single pnt */ 

drawline (pi , p2 , pb , s ,m ,d) = copybl t (pb , s ,m , d) ; 

else if ltint( 

absint (subint (ycord (p2 , ycord (pi) ) ) , 

abs in t (subint ( xcord (p2) , xcord (pi ) ) ) 

) = true ( ) 
then 

/* line is horizontal */ 
drawline (pi , p2 , pb , s ,m , d) = 
hdrawloop ( 

/* distance to go */ 

iton (absint ( subint (xcord (p2 ) ,xcord(pl) ) ) ) , 

/* dist till minor move counter */ 
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divint ( 

absint (subint (xcord Cp2) ,xcord (pi) ) ) ) , 

[2] succint (zeroint ( ) ) 

) , 

/* dx */ 
divint ( 

subint (xcord (p2) , xcord (pi) ) , 
absint (subint (xcord (p2) , xcord (pi) ) ) 

) , 

/* dy */ 
divint ( 

subint (ycord (p2) , ycord Cpl)), 
absint (subint (ycord (p2 ) ,ycord(pl) ) ) 

) , 

/* px */ 

absint (subint (ycord (p2) , ycord (pi) ) ) , 

/* PY V 

absint (subint (xcord (p2) ,xcord(pl) ) ) , 

s , 

copyblt (pb , s ,m, d) , 

m, 

pb 

) ; 

else 

/* line is vertical */ 
drawline ( pi , p2 , pb , s ,m , d) = 
vdrawloop ( 

/* dist to go */ 

iton (absint (subint (ycord (p2) , ycord (pi) ) ) ) , 

/* dist till minor move counter */ 
divint ( 

absint ( subint (ycord (p2) , ycord (pi) ) ) , 

[ 2 ] succint (zeroint ( ) ) 

) , 

/* dx */ 
divint ( 

subint (xcord (p2) , xcord (pi) ) , 
absint (subint (xcord (p2) ,xcord(pl) ) ) 

) , 

/* dy */ 
divint ( 

subint (ycord (p2) , ycord (pi) ) , 
absint ( subint (ycord ( p2 ) ,ycord(pl)) ) 

) , 

/* px */ 

absint ( subint (ycord (p2 ) ,ycord(pl) ) ) , 

/* py */ 

absint ( subint (xcord (p2 ) , xcord ( pi) ) ) , 

s, 

copyblt ( pb , s ,m, d) , 
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m, 

pb 

) ; 

end if ; 
endif ; 

/'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k-k'k'klc'k'k-k-k'k'k-k-k-k'kic 

* copyfont 

* p: position in destination for lower left 

corner of source form 

* pb : ptblt 

* id: index number 

* ft: font with source form 

* m: mask 

* d: destination form 

***************************************** ^/ 
copyfont (p,pb , id , ft ,m,d) = copyblt( 
setdrct (. 

putrct (p , rctfont (ft) ) , 
setsrct ( rctf ont ( ft ) ,pb) 

) 

getfont (id, ft) , 

m, 

d, 

) ; 

^/**************************************** 

* invcopyfont 

* cl: foreground color 

* c2: background color 

* p: position in destination for lower left 

corner of source form 

* pb : ptblt 

* id: index number 

* ft: font with source form 

* m: mask 

* d: destination form 
***************************************** 

invcopyfont (cl , c2 , p , pb , id , ft ,m , d) = copyblt( 
setdrct ( 

putdrct (p , rctfont ( ft ) ) , 
setsrct (rctfont ( ft) ,pb) 

) 

invform (cl , c2 , getfont ( id , ft ) ) , 

m, 

d, 

) ? 

end extend; 
end pntblktrans ; 
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spec identifiers 
is 



extend 

boolean 

with 

sort 

mem id ; 
regid ; 
stkid ; 
dregid ; 
f id ; 



qid; 


/* 


queue ID */ 


dbid ; 
primitive 
op 


/* 


database ID */ 


idopers (memid , memseg) ; 


/* 


memory seg id */ 


idopers ( regid , regseg) ; 


/* 


register seg id 


idopers ( stkid , stkseg) ; 


/* 


stack seg id */ 


idopers (dregid, dregseg) ; 


/* 


display register 
seg id */ 


idopers (qid , qseg) ; 
axiom 


/* 


queue segment ID 



idaxioms (memid ,memseg) ; 
idaxioms (regid , regseg) ; 
idaxioms ( stkid , stkseg) ; 
idaxioms (dregid , dregseg) 
idaxioms (qid , qseg) ; 
end extend; 
end identifiers; 



V 



V 



spec memaddress 
is 

extend 

identifiers , 
boolean 
with 

sort 

memaddr ; 
primitive 
op 

startmemaddr : memid -* memaddr; 

nextmemaddr ; memaddr memaddr ; 

prevmemaddr : memaddr -* memaddr ; 

getmemid: memaddr -> memid; 

offset: int,memaddr ■* memaddr; /* offset from 

memaddr */ 

aqmemaddr: memaddr , memaddr -* bool; 
axiom 

prevmemaddr ( startmemaddr ( i) ) = undef; 

prevmemaddr ( nextmemaddr (m) ) = m; 
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nextmemaddr (prevmemaddr (m) 1 = m; 

off set (succint ( n ) ,m) = nextmemaddr (of fset (_n ,m) ) ; 

if offset (n,m) = s tartmemaddr ( ) 

then 

of fset (predint (n) ,m) = undef; 
else 

of fset (predint (n) ,m) = prevmemaddr (of fset (n , m) ) 
endif ; 

eqmemid (,i , getmemid (of f set (n , startmemaddr (i) ) )) = 

true ( ) ; 

eqmemaddr ( startmemaddr ( il). , startmemaddr (i2) ) = 

eqmemid ( i 1 , i 2 ) ; 

eqmemaddr ( startmemaddr ( i) , nextmemaddr ( a) ) = 

false ( ) ; 

eqmemaddr (nextmemaddr (al) , nextmemaddr (a2) ) = 

eqmemaddr (al , a2) ; 
of f set (zeroint ( ) ,m) = m; 
equivrel (eqmemaddr ,memaddr) ; 
end extend; 
end memaddress ; 



spec regaddress 
is 

extend 

identifiers , 
boolean 
with 

sort 

regaddr ; 
primitive 
op 

startregaddr : regid -*■ regaddr; 
nextregaddr : regaddr -»■ regaddr; 
prevregaddr: regaddr regaddr; 
getregid: regaddr regid; 
eqregaddr : regaddr , regaddr ->■ bool ; 
axiom 

prevregaddr ( startregaddr ( i) ) = undef; 

prevregaddr (nextregaddr (m) ) = m; 

nextregaddr (prevregaddr (m) ) = m; 

eqregaddr ( startregaddr ( il) , startregaddr ( i2 ) ) = 

eqregid ( il , i 2 ) ; 

eqregaddr ( startregaddr ( i) , nextregaddr ( a) ) = 

false ( ) ; 

eqregaddr (nextregaddr (al ) , nextregaddr (a2) ) = 

eqregaddr (al , a2) ; 
equivrel ( eqregaddr , regaddr ) ; 
end extend; 
end regaddress; 
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spec stkaddress 
is 

extend 

identifiers , 
boolean 
with 

sort 

stkaddr ; 
primitive 
op 

getstkid: stkaddr -»■ stkid; 

eqstkaddr: stkaddr , stkaddr -*■ bool; 
axiom 

eqstkaddr (nextstkaddr (al) ,nextstkaddr (a2) ) = 

eqstkaddr (al ,a2) ; 

equivrel ( eqstkaddr , stkaddr ) ; 
end extend; 
end stkaddress ; 



spec qaddress /* database part */ 

is 

extend 

identifiers , 
boolean 
with 

sort 

qaddr ; 
primitive 
op 

getqid: qaddr qid; 
eqqaddr : qaddr, qaddr -»■ bool; 
axiom 

eqqaddr (nextqaddr (al) , nextqaddr (a2) ) = 

eqqaddr (.al, a2) ; 
equivrel (eqqaddr , qaddr ) ; 
end extend; 

end qaddress; /* database part */ 



spec dregaddress /* display part */ 

is 

extend 

identifiers , 
boolean 
with 

sort 

dregaddr ; 
primitive 
op 

startdregaddr : dregid dregaddr; 
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nextdregaddr: dregaddr -*■ dregaddr; 
prevdregaddr : dregaddr dregaddr; 
getdregid: dregaddr -*■ dregid; 
eqdregaddr : dregaddr , dregaddr bool; 

axiom 

prevdregaddr ( startdregaddr ( i) ) = undef; 

prevdregaddr (nextdregaddr (m) ) = m; 
nextdregaddr (prevdregaddr Cm) ) = m; 

eqdregaddr (startdregaddr (il) , startdregaddr ( i 2 ) ) = 

eqdregid (il ,i2) ; 

eqdregaddr (startdregaddr ( i) , nextdregaddr (a) ) = 

false ( ) ; 

eqdregaddr (nextdregaddr (al) , nextdregaddr (a2 ) ) = 

eqdregaddr (al , a2 ) ; 
equivrel (eqdregaddr , dregaddr ) ; 
end extend; 
end dregaddress ; 



spec monitorattribute 
is 

extend 

boolean 

with 

sort 

mattribute ; 
primitive 
op 

xpixels: -*■ mattribute; 
ypixels: -»■ mattribute; 
hscrnsize: mattribute; 

vscrnsize: -*■ mattribute; 
intenscapbl : mattribute; 

colorcapbl: -»■ mattribute; 
backgnd: -> mattribute; 
dselect: -> mattribute; 

eqmattribute : mattribute , mattribute -* bool; 
axiom 

equivrel (eqmattribute , mattribute) ; 
end extend; 

end monitorattribute; /* display part */ 



spec files 
is 



extend 

identifiers , 
boolean 
with 

sort 

file ; 
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primitive 

op 

getfile: fid file; 
eqfile: file, file ->■ bool; 
axiom 

eqfile (getfile ( il) , getfile ( i2) ) = eqf id ( il , i2 ) ; 
equivrel (eqfile, file) ; 



end extend; 
end files; 

spec operatorclasses 
is 

sort 

mop; 

dop; 

top; 

q°p ; 

sop; 

oop; 

rop; 

bop; 

end operatorclasses; 

spec ins truction type 
is 

sort 

instr ; 

end ins truct iontype ; 

spec property_id /* database part */ 

is 

extend 

boolean 

with 

sort 

pid; 

primitive 

op 



pidl : pid ; 

pid2: pid; 



/* 1st property_id */ 
/* 2nd property_id */ 



pidn: ->■ pid; 

eqpid: pid, pid bool; 



/* nth property_id */ 

/* equal property_id */ 



axiom 



equivrel (eqpid , pid) ; 



end extend; 
end property_id; 
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spec property_idset 
is 

extend 

boolean , 
prope rty_id 
with 

sort 

pidset ; 
primitive 
op 

0: -*■ pidset; /* empty set */ 

u: ->■ pidset; /* universe */ 

crpidset: pid -»■ pidset; /* create */ 

unpidset: pidset , pidset -*■ pidset; 

/* union */ 

intpidset: pidset , pidset pidset; 

/* intersection */ 

mempidset: pid, pidset -»• bool; /* member */ 
eqpidset: pidset , pidset + bool; 

/* equal */ 

axiom 

eqpidset (0 , 0 ) = true ( ) ; /* empty pidset */ 

if eqpidset (psl , ps2) = true ( ) 

then 

(eqpidset (unpidset (psl , crpidset (pdl) ) , 

unpidset (ps2 , crpidset (pd2 )) ) = 

eqpid (pdl ,pd2) ) ; 

endif; /* ps : 'pidset' */ 

/* pd: 'pid' */ 

mempidset (pdl , crpidset (pdl) ) = true ( ) ; 
if mempidset (pd2 , crpidset (pdl) ) = true ( ) 

then 

eqpid (pdl , pd2) = true ( ) ; 
endif ; 
if and ( 

eqpidset (psl ,ps2) , 
eqpidset (ps2 ,ps3) 

) = true ( ) 
then 

eqpidset (unpidset (psl ,ps2) ,ps3) = true ( ) ; 

eqpidset (intpidset (psl ,ps2) ,ps3) = true ( ) ; 
endif ; 
if and ( 

eqpidset (psl , ps2) , 
eqpidset (ps2 ,ps3) 

) = true ( ) 
then 

unpidset (psl ,ps2) = unpidset (ps2 ,ps3) ; 

intpidset (psl , ps2) = intpidset (ps2 ,ps3) ; 
else unpidset ( 

unpidset (psl ,ps2) , 
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unpidset (ps2 , ps3 ) 

) = unpidset ( 

unpidset (psl ,ps2) , 
ps3 

) ; 

intpidset ( 

intpidset (psl , ps2) , 
intpidset (ps2 ,ps3 
) = intpidset ( 

intpidset (psl , ps2 ) , 
ps3 



endif ; 

mempidset (pdl , unpidset (psl , ps2) ) 

= or ( 

mempidset ( pdl , psl ) , 
mempidset (pdl ,ps2) 

) ; 

mempidset (pdl , intpidset (psl , ps 2) ) 

= and ( 

mempidset (pdl , psl) , 
mempidset (pdl ,ps2) 

) ; 

if eqpidset (unpidset (psl ,ps2) , intpidset (psl ,ps2) ) 

= trued 



then 

eqpidset (psl ,ps2) = true ( ) ; 
endif ; 
if and( 

and ( 

not ( eqpid ( pdl , pd3) ) , 
not (eqpid (pd2 , pd3) ) 

) , 

eqpidset ( unpidset ( crpidset (pdl ) , 
crpidset (pd2) ) ,ps3) 

) = true ( ) 

then 

mempidset (pd3 ,ps3) = false(); 
endif ; 

associative ( unpidset , pidset) ; 
associative ( intpidset , pidset) ; 
commutative (unpidset , pidset) ; 
commutative ( intpidset , pidset) ; 
equivrel (eqpidset , pidset) ; 
end extend; 
end property_idset ; 



spec value 
is 

extend 

boolean 
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with 

sort 

val ; 

primitive 

op 

vail: ■* val; 
val 2: -> val; 



vain: ■+ val; 
eqval: val, val -> bool; 
axiom 

equivrel (eqval , val) ; 
end extend; 
end value; 



spec valueset 
is 

extend 

boolean , 
value 
with 

sort 

valset ; 
primitive 
op 

0: -> valset; /* empty set */ 

u: valset; /* universe */ 

crvalset: val -*■ valset; /* create */ 

unvalset: valset , valset -»■ valset; 

/* union */ 

intvalset: valset , valset ■+ valset; 

/* intersection */ 

memvalset: val, valset -> bool; /* member */ 
eqvalset: valset , valset -> bool; 

/* equal */ 

axiom 

eqvalset ( 0 , 0 ) = true (); /* empty valset */ 

if eqvalset (vsl , vs2) = true ( ) /* vs: 'valset' */ 

then 

(eqvalset (unvalset (vsl , crvalset (vl) ) , 

unvalset (vs2 , crvalset (v2) ) ) = 

eqval (vl , v2) ) ; /* v: 'val' */ 

endif ; 

memvalset (v , crvalset (v) ) = true ( ) ; 

if memvalset (v2 , crvalset (vl) ) = true ( ) 

then 

eqval(vl,v2) = true(); 
endif ; 



/* 1st value */ 
/* 2nd value */ 



/* nth value */ 

/* equal value */ 
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if and( 

eqvalset (_vsl , vs3) , 
eqvalset ( vs 2 , vs 3) 

) = true ( ) 
then 

eqvalset ( unvalset (vsl , vs2) ,vs3 ). = true ( ) ; 
eqvalset (intvalset (vsl ,vs2 ) ,vs3) = true(); 
endif ; 
if and ( 

eqvalset (vsl ,vs2) , 
eqvalset (vs 2 , vs 3) 

) = true ( ) 

then 

unvalset (vsl , vs2 ) = unvalset (vs2 ,vs3) ; 
intvalset (vsl , vs2 ) = intvalset (vs2 , vs3 ) ; 
else unvalset ( 

unvalset (vsl ,vs2) , 
unvalset (vs 2 , vs 3) 

) = unvalset ( 

unvalset (vsl ,vs2 ) , 
vs 3 

) ; 

intvalset ( 

intvalset (vsl ,vs2) , 
intvalset (vs 2 , vs 3) 

) = intvalset ( 

intvalset (vsl , vs2 ) , 
vs3 

) ; 

endif ; 

memvalset ( vl , unvalset ( vsl , vs 2 ) ) 

= or ( 

memvalset (vl , vsl) , 
memvalset (vl , vs 2) 

) ; 

memvalset ( vl , intvalset (vsl , vs 2) ) 

= and ( 

memvalset (vl , vsl ) , 
memvalset (vl , vs 2) 

) ; 

if eqvalset (unvalset (vsl ,vs2) , intvalset (vsl , vs2 ) ) 

= true ( ) 

then 

eqvalset ( vsl , vs2 ) = true ( ) ; 
endif ; 
if and( 

and ( 

not ( eqval ( vl , v3 ) ) , 
not (eqval ( v2 , v3 ) ) 

) , 
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eqvalset (unvalset (crvalset (vl , 

crvalset (,v2) ) ,vs3) 

) = true ( ) 
then 

memvalset (v3 , vs3) = falseO; 
endif ; 

associative (unvalset ,valset) ; 
associative ( intvalset , valset) ; 
commutative (unvalset , valset) ; 
commutative (intvalset , valset) ; 
equivrel (eqvalset, valset) ; 
end extend; 
end valuset; 



spec property 
is 

extend 

boolean , 
property_id , 
property_idset , 
value , 
valueset 
with 

sort 

prop; 

primitive 

op 

crprop: pid, valset -* prop; /* create */ 

eqprop : prop, prop -*■ bool; /* equal */ 

getid: prop -*■ pid; /* get property_id */ 

getvalset: prop -* valset; /* get valueset */ 

axiom 

if and ( 

eqpid (getid (prl) , getid (pr2) ) , 
eqvalset (getvalset (prl) , getvalset (pr2) ) 

) = true ( ) 

then /* pr : property */ 

eqprop (prl , pr2 ) = true ( ) ; /* pd : property_id */ 

endif ; 

getid (crprop (pdl ,vsl) ) = pdl ; 
getvalset (crprop (pdl , vsl) ) = vsl ; 
equivrel (eqprop, prop) ; 
end extend; 
end property; 



spec propertyset 
is 

extend 

boolean , 
property_id , 
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property_idset , 
value , 
valueset , 
property 

with * 

sort 

propset ; 
primitive 
op 

0: ->■ propset; /* empty set */ 

u; -»■ propset; /* universe */ 

crpropset: prop -»■ propset; /* create */ 

unpropset: propset , propset -+• propset; 

/* union */ 

intpropset: propset , propset ->■ propset; 

/* intersection */ 
mempropset: prop, propset -»■ bool; 

/* member */ 

getidset: propset -> pidset; /* get pidset */ 
eqpropset: propset ,propset -*■ bool; 

/* equal propset */ 



axiom 

eqpropset ( 0 , 0 ) = true ( ) ; /* empty propset */ 

if eqpropset (prsl , prs2 ) = true ( ) 

/* prs : 'propset' */ 

then 

(eqpropset (unpropset (prsl , crpropset (prl) ) , 

unpropset (prs2 , crpropset (pr2 ) ) ) = 

eqprop ( pr 1 , pr 2 ) ) ; 

endif; /* pr : 'prop' */ 

mempropset (pr , crpropset (pr) ) = true () ; 

if mempropset (pr2 , crpropset (prl) ) = true ( ) 
then 

eqprop (prl , pr2) = true ( ) ; 
endif ; 
if and( 

eqpropset (prsl ,prs3) , 
eqpropset (prs 2 , prs3) 

) = true ( ) 



then 

eqpropset (unpropset (prsl , prs2 ), prs3 ) = true(); 
eqpropset ( intpropset (prsl ,prs2) ,prs3) = true ( ) ; 
endif ; 
if and ( 

eqpropset (prsl ,prs2) , 
eqpropset (prs2 ,prs3) 

) = true ( ) 

then 

unpropset (prsl , prs2) = unpropset (prs2 , prs3) ; 
intpropset (prsl ) prs2) = intpropset (prs2 , prs3) ; 
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else unpropset( 

unpropset (prsl , prs 2 ) , 
unpropset (prs2 ,prs3)_ 

) = unpropset ( 

unpropset (prsl ,prs2 ) , 
prs3 

) ; 

intpropset ( 

intpropset (prsl ,prs2) , 
intpropset ( prs 2 , prs3) 

) = intpropset (, 

intpropset (prsl ,prs2) , 
prs3 

) ; 

end if ; 

mempropset (pr , unpropset (prsl , prs 2 ) ) 

= or ( 

mempropset (pr , prsl ) , 
mempropset (pr ,prs2) 

) ; 

mempropset (pr , intpropset ( prsl , prs2) ) 

= and ( 

mempropset (pr , prsl) , 
mempropset (pr ,prs2) 

) ; 

if eqpropset (unpropset (prsl , prs 2 ) , 

intpropset (prsl , prs2 ) ) = true ( ) 

then 

eqpropset (prsl ,prs2) = true(); 
endif ; 
if and ( 
and ( 

not (eqprop (prl ,pr3) ) , 
not (eqprop (pr2 ,pr3) ) 

) , 

eqpropset (unpropset (crpropset (prl) , 

crpropset (pr2) ) ,prs3) ) = true ( ) 

mempropset (pr3 ,prs3) = falseO; 
endif ; 

if mempropset (crprop (pd , vs) , prs) = true ( ) 

/* pd: 'pid' */ 

then /* vs: 'valset' */ 

mempidset (pd ,getidset (prs ) ) = true ( ) ; 
endif; ^ 

associative ( unpropset , propset) ; 
associative ( intpropset , propset) ; 
commutative ( unpropset , propset) ; 
commutative ( intpropset , propset) ; 
equivrel ( eqpropset , propset) ; 
end extend; 
end propertyset; 



theA = tn > e(l 
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/*pr : property*/ 



spec propertyvalue 
is 



extend 

boolean , 
proper ty_id, 
property_idset , 
value , 
valueset , 
property 
with 

sort 

pval ; 
primitive 
op 

crpval: pid,val pval; /* create */ 

getpid: pval -*■ pid; /* get property_id */ 

getval : pval val ; /* get 

propertyvalue */ 



eqpval: pval, pval bool; 
memprop: pval, prop -»■ bool; 
axiom 

getpid (crpval (pd ,va) ) = pd; /* pd: property_id */ 

getval (crpval (pd ,va) ) = va; /* va : value */ 

if and ( 

eqpid(getpid (pv) ,getid(pr) ) , 
memvalset (getval (pv) , getval set (pr ) ) 

) = true ( ) /* pv: 

propertyvalue */ 



then 

memprop (pv,pr) = true ( ) ; 
endif ; 
if and ( 

memprop (pvl , pr) , 
memprop ( pv2 , pr ) 

) = true ( ) 



then 

eqpid (getpid (pvl) , getpid (pv2) ) = true ( ) ; 

endif ; 

if eqpval (crpval (pdl , val ) , crpval (pd2 , va2) ) 

= true ( ) 

then and( 

eqpid (pdl ,pd2) , 
eqval (val , va2 ) 

) = true ( ) ; 
endif; •* 

equivrel (eqpval , pval) ; 
end extend; 
end propertyvalue; 



204 



spec propertyvalueset 
is 

extend 

boolean , 
property_id , 
property_idset , 
value , 
valueset , 
property , 
propertyvalue 
with 

sort 

pvalset ; 
primitive 
op 

0: -*• pvalset; /* empty set */ 

u: pvalset; /* universe */ 

crpvalset: pval -*• pvalset; /* create */ 

unpvalset: pvalset , pvalset pvalset; 

/* union */ 

intpvalset: pvalset , pvalset pvalset; 

/* intersection */ 
mempvalset: pval, pvalset -»■ bool; 

/* member */ 

mempset: pvalset , propset -»■ bool; 

/* member propset */ 

getpidset; pvalset -»■ pidset; /* get pidset */ 
eqpvalset: pvalset , pvalset bool; 

/* equal */ 

axiom 

eqpvalset ( 0 , 0 ) = true ( ) ; /* empty pvalset */ 

if eqpvalset (pvsl , pvs2 ) = true ( ) 

/* pvs : 'pvalset' */ 

then 

(eqpvalset (unpvalset (pvsl , crpvalset 

(crpval (pdl , vl) ) ) , 
unpvalset (pvs2 , crpvalset 

(crpval (pd2 ,v2) )) ) = 

eqpval (crpval (pdl ,vl) , crpval (pd2 , v2) ) ) ; 
endif; /* pd : 'pid' */ 

/* v : ' val ' */ 

mempvalset (pv , crpvalset (pv) ) = true ( ) ; 

/* pv : 'pval' */ 

if mempvalset (pv2 , crpvalset (pvl) ) = true ( ) 
then 

eqpval (pvl , pv2) = true ( ) ; 
endif ; 
if and( 

eqpvalset (pvsl , pvs3 ) , 
eqpvalset (pvs 2 , pvs 3 ) 

) = true ( ) 
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then 

eqpvalset (unpvalset (pvsl ,pvs2) , pvs3) = true ( ) ; 
eqpvalset (intpvalset (.pvsl, pvs2) ,pvs3) = trued; 
endif ; 

•if and( 

eqpvalset (pvsl ,pvs 2) , 
eqpvalset (pvs2 ,pvs3) 

) - true ( ) 
then 

unpvalset (pvsl , pvs2 ) = unpvalset (pvs2 , pvs3 ) ; 
intpvalset (pvsl , pvs2 ) = intpvalset (pvs2 , pvs3 ) ; 
else unpvalset ( 

unpvalset (pvsl ,pvs2) , 
unpvalset (pvs2 ,pvs3) 

) = unpvalset ( 

unpvalset (pvsl , pvs2) , 
pvs3 

) ; 

intpvalset ( 

intpvalset (pvsl ,pvs2) , 
intpvalset (pvs2 ,pvs3) 

) = intpvalset ( 

intpvalset (pvsl , pvs2). , 
pvs3 

) ; 

endif ; 

mempvalset (pv , unpvalset (pvsl,pvs2) ) 

= or ( 

mempvalset (pv, pvsl) , 
mempvalset (pv,pvs2) 

) ; 

mempvalset (pv, intpvalset (pvsl , pvs2) ) 

= and ( 

mempvalset (pv, pvsl ) 
mempvalset (pv,pvs2) 

) ; 

if eqpvalset (unpvalset (pvsl , pvs2 ) , 

intpvalset (pvsl ,pvs2) ) = true ( ) 

eqpvalset (pvsl ,pvs2) = true ( ) 
endif ; 
if and ( 
and ( 

not (eqpval (pvl , pv3) ) , 
not (eqpval (pv2 ,pv3) ) 

) , 

eqpvalset (unpvalset (crpvalset (pvl) , 

crpvalset (pv2) ) ,pvs3) ) = trued 

then 

mempvalset (pv3 ,pvs3) = falsed; 
endif ; 

if mempvalset (crpval (pd, v) ,pvs) = trued 
then 

mempidset (pd , getpidset (pvs) ) = trued; 
endif ; 



then = true() 
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if eqpidset (getpidset (pvs) , getidset (prs) ) = true ( ) 
then /* prs: 'propset' */ 

mempset (pvs ,prs) = true ( ) ; 
endif ; 

associative ( unpvalset , pvalset) ; 
associative ( intpvalset , pvalset) ; 
cummutative ( unpvalset , pvalset ) ; 
commutative ( intpvalset , pvalset) ; 
equivrel (eqpvalset , pvalset) ; 
end extend; 
end propertyvalueset ; 



spec object 
is 



extend 

boolean 
property_id 
property_idset , 
value , 

propertyvalue , 
propertyvalueset 
with 

sort 
obj ; 

primitive 

op 

crob j : pvalset -* ob j ; 
getopvalset: obj pvalset; 

getopidset: obj -> pidset; 

getoval: obj,pid -> val ; 
haspval: pval,obj -> bool; 

eqob j : obj , obj -* bool; 
axiom 

getopvalset (crobj (pvs) ) = pvs ; 
if mempvalset (pv,pvs) = true ( ) 



/* create */ 

/* get 

propertyvalueset */ 
/*get 

property_idset */ 

/* get value */ 

/* has 

propertyvalue */ 

/* equal */ 

/* pvs: 'pvalset' */ 

/* /pv: 'pval' */ 



then 

haspval (pv, crob j (pvs) ) = true ( ) ; 
endif ; 

getopidset (crobj (pvs) ) = getpidset (pvs) ; 
if and ( 

(crpval (pd, v) = pv) , /* pd : 'pid' */ 

mempvalset (pv, pvs) /* v: 'val' */ 

) = true ( ) 



then 

getoval (crob j (pvs) ,pd) = v; 
endif ; 
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if eqpvalset (.pvsl ,pvs2) = trueO 
then 

eqob j (crob j (pvsl ) , crob j (pvs2 ) ) = true Q ; 
end if ; 

eqobj(ol,o2) = /* o: 'obj ' */ 

eqpvalset (getopvalset (ol) ,getopvalset (o2) ) ; 
equivrel (eqobj ,ob j ) ; 
end extend; 
end object; 



spec objectclass 
is 



extend 

boolean , 
property_id , 
property_idset , 
obj ect 
wi th 

sort 

class ; 
primitive 
op 

0: -* class; 
u: class; 

crclass: obj -* class; 
unclass: class,class class; 
intclass: class, class ->■ class 
subclass: class, class -»■ bool; 
memclass: obj, class -* bool; 
getcpidset: class pidset; 

insob j : class, obj class; 
delobj : obj,class -> class; 
eqclass: class, class -* bool; 
axiom 

eqclass(0,0) = true ( ) ; 
if eqclass (cl , c2 ) = trueO 
then 

eqclass (unclass (cl, crclass 
unclass (c2, crclass 
eqpvalset (pvsl ,pvs2) ; 
end if ; 
if and ( 

eqobj (ol ,o2) , 
eqclass (cl , c2 ) 

) = true ( ) 



/* empty class */ 

/* universe */ 

/* create */ 

/* union */ 

; /* intersection */ 

/* subclass */ 

/* member */ 

/* get pidset 
of class */ 

/* insert */ 

/* delete */ 

/* equal */ 

/* empty class */ 

/* c : 1 class ' */ 

(crob j (pvsl ) ) ) , 

(crobj (pvs2 ) ) ) ) = 

/* pvs: 'pvalset' */ 



/* o: ’obj ' */ 



then 

eqclass (insob j (ol , cl) , insobj (o2 ,c2) ) = trueO; 
endif ; 
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memclass (o , crclass (o) ) = true ( ) ; 
if memclass (o2 , crclass Col) } = true ( ) 
then 

eqobj(ol,o2) = true ( ) ; 
endif; 
if and( 

eqclass (cl , c3) , 
eqclass (c2 , c3) 

) - true ( ) 
then 

eqclass (unclass (cl , c2) , c3) = true(); 
eqclass (intclass (cl ,c2) ,c3) = true ( ) ; 
endif ; 
if and ( 

eqclass (cl ,c2) , 
eqclass (c2 , c3) 

) = true() 
then 

unclass (cl , c2) = unclass (c2 ,c3) ; 
intclass ( cl , c2 ) = intclass (c2 , c3 ) ; 
else unclass ( 

unclass (cl , c2) , 
unclass (c2 ,c3) 

) = unclass ( 

unclass (cl ,c2) , 
c3 

) ; 

intclass ( 

intclass (cl , c2 ) , 
intclass (c2 , c3) 

) = intclass (. 

intclass (cl , c2 ) 
c3 

) ; 

endif ; 

memclass (o , unclass (cl , c2 ) ) 

= or ( 

memclass (o,cl) , 
memclass (o , c2) 

) ; 

memclass (o , intclass (cl , c2) ) 

= and ( 

memclass (o , cl) , 
memclass (o , c2) 

J ; 

if and( 

and( 

not(eqobj (ol,o2) ) , 
not ( eqob j (o2 , o3 ) ) 

) , 

eqclass (unclass (crclass(ol) ,crclass(o2) ) ,c3) 
) = true ( ) 
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false C) ; 



then 

memclass (o3 , c3) = 
endif ; 
if and( 

memclass (ol , c) , 
memclass (o2 , c) 

) = true ( ) 
then 

eqpidset ( getopidset (ol) , getopidset (o2 ). ) = true ( ) 
endif ; 

if eqclass (unclass (cl ,c2) , cl) = true ( ) 
then 

subclass (c2 , unclass (cl ,c2) ) = true ( ) ; 

else if eqclass (unclass ( cl , c2 ), c2 ) = true ( ) 
then 

subclass (cl , unclass (cl ,c2) ) = true ( ) ; 

else and ( 

subclass (cl , unclass (cl ,c2) ) , 
subclass (c2,unclass (cl,c2) ) 

) = true ( ) ; 
endif ; 

delob j (o , in sob j (c ,o) ) = c; 

getcpidset ( crclass (o) ) = getopidset (o) ; 

if not (memclass (ol , c) ) = true ( ) 

then 

delob j(ol,c) = undef; 

else delobj(ol,unclass(crclass(ol) ,crclass(o2))) 

= crclass (o2 ) ; 

endif ; 

if not (eqpidset (getopidset (ol) , getcpidset (c) ) ) 

= true ( ) 

then 

insobj(c,ol) = undef; 

else insob j ( crclass (o2 ), ol ) = unclass (crclass (o2) , 

crclass (ol ) ) ; 

endif ; 

if eqclass ( intclass (cl , c2 ), cl ) = true ( ) 
then 

subclass (cl , c2) = true ( ) ; 
endif ; 

associative (unclass ,class) ; 
associative (intclass, class) ; 
commutative (unclass , class) ; 
commutative ( intclass , class ) ; 
equivrel (eqclass, class) ; 
end extend; 
end objectclass; 
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spec database 
is 

extend 

property_id , 
property_idset , 
value , 
valueset , 
property, 
property set , 
propertyvalue , 
propertyvalueset , 
object , 
ob jectclass , 
identifiers 
with 

sort 
db ; 

primitive 

op 

crdb : dbid, class -*■ 
insclass: db, class 
delclass: class, db 
retclass: db, class 



db ; 

-»■ db ; 

-* db; 

-»• pvalset; 



retob j : db,pval -*■ obj ; 

getdbpidset: db pidset; 
modobj ; db,obj,pval -> db ; 
getdb : dbid ■+■ db ; 
getdbid: db ■+ dbid; 
memdb ; class, db -»■ bool; 
eqdb ; db , db -> bool; 
eqdbid: dbid, dbid bool; 
axiom 

if eqdb(dl,d2) = true ( ) 



/* create */ 

/* insert new class */ 
delete class */ 

/* retrieve pvalset 
of class */ 
retrieve obj by 
pval */ 
get pidset */ 
modify obj */ 
get db by ID */ 
get ID of db */ 

/* member */ 

/* equal db */ 

/* equal ID */ 



/* 

/* 

/* 

/* 

/* 

/* 



/* d: 'db' */ 



then 

eqdb (insclass (dl , cl) , insclass (d2,c2) ) = 
eqclass (cl ,c2) ; 
end if ; 

memdb ( c , crdb ( i , c) ) = true ( ) ; /* c: 'class' */ 

memdb ( c , insclass (d , c) ) = true ( ) ; 

/* 

delclass (c , insclass (d , c) ) = d; 
if and( 

and ( 

eqpvalset (getopvalset (o) ,pvs) , 

/* o : ' ob j ' */ 



c : 1 class ' 

i: ID */ 



memclass (o , c) 

) , 

memdb ( c , d) 

) = true ( ) 



/* pvs : 'pvalset' */ 
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then 

intpvalset ( retclass (d , c) , pvs) = pvs ; 
endif ; 
if and( 

and ( 

haspval (pv,o) , /* pv: 'pval' */ 

memclass (o , c) 

) , 

memdb (c , d) 

) = true ( ) 
then 

retobj (d,pv) = o; 
endif ; 

if not (memdb (cl , d) ) = true() 
then 

delclass ( cl , d) = undef; 
else delclass (cl , crdb ( i , unclass (cl , c2) ) ) = 

crdb ( i , c2) ; 

endif ; 

if memdb (cl,d) = true() 
then 

insclass (d, cl) = undef; 
else if and ( 

and( 

not (memdb (cl , d) ) , 
memdb (c2 ,d) 

) , 

not (eqpidset (getcpidset (cl) , 
getcpidset ( c2 ) ) ) 

) = true (.) 
then and( 

eqclass (insclass (crdb (i , c2) ,cl) , 

crdb ( i , unclass (cl , c2) ) ) , 
eqpidset (getdbpidset (d) ,unpidset 

(getcpidset (cl) , getcpidset ( c2 ) ) ) 

) = true ( ) ; 
endif ; 
if and( 

and ( 

memclass (o , c) , 
haspval (pv,o) 

) , 

memdb ( c , d ) 

) = true ( ) 
then 

mempvalset (pv , retclass (d , c ) ) = true ( ) ; 
endif ; 
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if and( 

and (. 
and ( 

and( /* pv: 'pval' */ 

memprop (pv , crprop (pd , vs) ) , 

/* pd: 'pid' */ 

mempidset (pd ,getidset (prs) ) 

/* vs: 'valset' */ 

) , /* prs: 'propset' */ 

eqpidset (getopidset (o) ,getidset (prs) ) 

) , /* o: 'obj ' */ 

memclass (o ,c) /* d: 'db' */ 

) , 

memdb (c ,d) 

) = true ( ) 
then and ( 

haspval (pv,o) , 

memdb (crclass (o) ,modob j (d ,o , pv) ) 

) = true ( ) ; 

else modob j (d , o ,pv) = undef; 
endif; 

getdbid (crdb ( i , c) ) = i; 

if eqdb (getdb (il) ,getdb (i2) ) = true ( ) 

then 

eqdbid ( il , i2) = true ( ) ; 

endif ; 

equivrel (eqdb , db) ; 
equivrel (eqdbid , dbid) ; 
end extend; 
end database; 



spec list 
parm 

extend 

boolean , 
string 
with 

sort 

elm; 

primitive 

op 

eqelm: elm, elm -*• bool; /* equal */ 

axiom 

equivrel (eqelm, elm) ; 
end extend; 
is 

extend 

natural , 
boolean 
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with 

sort 

1st ; 

primitive 

op 

nullst: -*■ 1st; 
makelst: elm -> 1st; 

makenewlst: 1st -> 1st; 

firstelm: 1st elm; 

firstlst: 1st 1st; 

restlst: 1st -*■ 1st; 
catlst: 1st, 1st ->■ 1st; 

catelm: elm, 1st -*■ 1st; 



/* empty list */ 

/* make list from 
elm */ 

/* make list from 
list */ 

/* first elm of 
list */ 

/* first 1st of 
list */ 

/* rest of list */ 
/* concatenate two 
1st */ 

/* concatenate elm 
to 1st */ 



memelm: elm, 1st -*■ bool; 

memblst: 1st, 1st -*■ bool; 

lenlst: 1st -> nat; 
unlst: 1st, 1st 1st; 
intlst: 1st, 1st -»■ 1st; 
insist: 1st, 1st -+ 1st; 
deist: 1st, 1st -> 1st; 
getlst: 1st, 1st -> 1st; 
sofirstlst: 1st -> 1st; 

retobjlst: 1st, 1st -> 1st; 
modlst: 1st, 1st -* 1st; 
eqlst: 1st, 1st ->■ bool; 
axiom 

f irstelm (makelst (k) ) = k; 
firstelm(catlst (makelst (k) , 1) ) = k; 
firstelm (nullst () ) = undef; 

firstelm (makenewlst (makelst (k) ) ) = k; 

restlst ( catlst (makelst (k) , 1) ) = 1; 

restlst ( nullst () ) = undef; 

restlst (makelst (k) ) = nullstO; 
restlst ( catlst'( 11 , 12 ) ) = 12; 
f irstlst ( catlst ( 11 , 12 ) ) = 11; 
if makelst (k) = 1 
then 

firstlst (makelst (k) ) = 1; 
endif ; 

lenlst (nullst () ) = zeronatO ; 

lenlst (makelst (k) ) = succnat ( zeronat ( ) ) ; 



/* 


elm member of 




1st */ 




/* 


1st member of 




1st */ 




/* 


length 


of 1st * 


/* 


union * 


7 


/* 


intersection */ 


/* 


insert 


V 


/* 


delete 


V 


/* 


get lis 


:t */ 


/* 


set of 


first 




lists * 


/ 


/* 


retrieve objlst 


/* 


modify 


V 


/* 


equal * 


/ 
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lenlst (restlst ( 1) ) = subnat (lenlst (1) , 

succnat ( zeronat (.))); 

lenlst ( catlst ( 11 , 12 ) ) = sumnat (lenlst (11) , lenlst (12) ) 
if and( 

(1 ! = nullstO ) , 

(restlst (1) = nullstO) 

) = true ( ) 
then 

lenlst (1) = succnat ( zeronat () ) ; 

endif ; 

catlst (catlst ( 11 , 12) , 13) = catlst ( 11 , catlst ( 12 , 13 )) ; 
catlst (nullst (), 1) = catlst ( 1 , nullst () ) = 1; 

implies (eqelm (kl ,k2) , eqls t (makelst (kl) , 

makelst (k2) ) ) = true (.) ; 

gtnat ( lenlst (makelst (k) ), lenlst (nullst () ) = true ( ) ; 

if (lenlst(ll) != zeronatO) 

then 

gtnat (lenlst (catlst (11 , 12 ), lenlst ( 12 )) ) = true ( ) ; 
else eqnat ( lenlst ( catlst (11,12) , lenlst ( 12 ) ) ) 

- true ( ) ; 

endif ; 
if and ( 

( 11 = nullst ( ) ) , 

(12 = nullstO ) 

) = trueO 
then 

eqlst(ll,12) = true ( ) ; 
else if (f irstelm (11 ) != f irstelm (.12) ) 

then 

eqlst(ll,12) = falseO; 
else eqlst(restlst(ll) ,restlst(12)) ; 
endif ; 

if ( 1 = nullst ( ) ) 
then 

catelm(k,l) = makelst(k). ; 
else if (makelst(k) = nullstO) 
then 

catelm(k,l) = 1; 
else firstelm(l) = k; 
endif ; 

if ( 11 = nullst ( ) ) 
then 

unlst(ll,12) = 12; 

else if memelm(firstelm(ll) , 12) = true ( ) 

then 

unlst (restlst (11) ,12) ; 

else catelm ( f irstelm ( 11 ) , unlst ( restlst ( 11 ) ,12) ) ; 
endif; 

memelm ( f irstelm ( 1 ), 1) = true(); 

memelm (k , makelst (k) ) = true ( ) ; 

eqlst (1 ,makenewlst (restlst ( 1) ) ) = falseO; 

equivrel (eqlst , 1st ) ; 



215 



if eqlst ( f irstlst (.11 ) , nullst ( ) ) = 

/* 



then 



true Q 

recursion for 
memblst */ 



memblst (11 , 12) = true ( ) ; 
else if and ( 

not (eqlst (f irstlst (11) ; nullst () ) = true ( ) ) , 
(eqlst ( f irstlst ( 1 2 ), null st () ) = true()) 

) = true ( ) 

then 



memblst ( 11 , 12) = falseO; 

else if eqlst ( f irstlst (11) , f irstlst (12) ) = true ( ) 
then 

memblst (restlst ( 11) ,restlst(12) ) ; 
else memblst (firstlst(ll) ,restlst(12)) ; 
endif ; 

if or( /* recursion for 

intlst */ 

(eqlst (11 , nullst () ) = true ( ) ) , 

( eqlst ( 12 , nulls t () ) = true ( ) ) 

) = true ( ) 
then 



intlst (f irstlst (11 ), 12) = nullstO; 
else if memblst ( f irstlst (11) , 12) = true ( ) 

then 

cat 1st (firstlst(ll) ,intlst(restlst(ll) ,12)) ; 
else intlst ( restlst ( 11) ,12) ; 
endif ; 

if or ( /* recursion for 

getlst */ 

(eqlst (11, nullst () ) = true ( ) ) , 

(eqlst ( 12 , nullst () ) = true ( ) ) 

) = true ( ) 
then 



getlst ( 11 , 12 ) = undef; 

else if eqlst ( f irstlst ( 11 ), 12) = true ( ) 

then 

getlst ( 11 , 12 ) = f irstlst ( (restlst (11) ) ; 

else if eqlst ( first 1st ( restlst ( 11 )), 12 ) = true ( ) 

then 

getls t ( 11 , 12 ) = f irstlst (11) ; 
else getlst ( restlst ( restlst ( 11) ) ,12) ; 
endif ; 

if or( /* recursion for 

deist */ 

(eqlst ( 12 , nullst () ) = true ( ) ) , 

(not (memblst (11 , 12) ) = true ( ) ) 

) = true ( ) 

then 

delst(ll,12) = undef; 

else if not (eqlst ( 11 , f irstlst ( 12) ) ) = true ( ) 
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then 

makenewls t (catlst(firstlst(_12) , deist ( 11 , 

restlst ( 12) ) ) ) ; 
else makenewlst (restlst (.12). ) ; 
endif ; 

if /* recursion for 

sofirstlst */ 

ltnat ( lenlst ( 1) , succnat (succnat ( zeronat ().))) 

= true ( ) 

then 

sof irstlst (1) = undef; 

else if eqnat (lenlst (1) , succnat (succnat (zeronat ())) ) 

= true ( ) 

then 

sof irstlst ( 1 ) = firstlst(l); 
else catlst ( f irstlst ( 1 ) , sof irstlst (restlst 

( restlst ( 1 ) ) ) ; 

endif ; 

if /* recursion for 

retobjlst */ 

eqlst ( f irstlst ( 11 ), nullst () ) = true ( ) 
then 

retob j 1st (11 , 12) = nullst (); 
else if intlst ( 12 , f irstlst ( 11 ) ) = 12 
then 

catlst (firstlst (11) , retob j 1st ( restlst ( 11 ) ,12) ) ; 
else retob j 1st (restlst ( 11) ,12) ; 
endif; 
if and ( 

and ( 
and ( 

and ( 

memblst ( 11 , makenewlst (uni st (12,13))), 
memblst (12,sofirstlst(14) ) 

) , 

(sofirstlst (15) = sof irstlst ( 14 ) ) 

) , 

memblst (15,16) 

) , 

memblst (16,17) 

) = true ( ) 
then 

memblst (makenewlst ( 15 ) , modlst (17,15,11) ) 

= true ( ) ; 

else modlst ( 17 , 15 , 11) = undef; 

endif ; 
end extend; 
end list; 
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spec pidlist 
is 

use 

list (property _id) 
where 

pid is elm; 
eqpid is eqelm; 
end pidlist; 



spec pidsetlist 
is 

use 

list (property_idset) 
where 

pidset is elm; 
eqpidset is eqelm; 
end pidsetlist; 



spec vallist 
is 

use 

list (value] 
where 

val is elm; 
eqval is eqelm; 
end vallist; 



spec valsetlist 
is 

use 

list ( valueset) 
where 

valset is elm; 
eqvalset is eqelm; 
end valsetlist; 



spec proplist 
is 

use 

list (property) 
where 

prop is elm; 
eqprop'is eqelm; 
end proplist • 



spec propsetlist 
is 

use 

list (propertyset) 
where 

propset is elm; 
eqpropset is eqelm; 
end propsetlist; 



spec pvallist 
is 

use 

list (propertyvalue) 
where 

pval is elm; 
eqpval is eqelm; 
end pvallist; 



spec pvalsetlist 
is 

use 

list (propertyvalueset) 
where 

pvalset is elm; 
eqpvalset is eqelm; 
end pvalsetlist; 



spec objlist 
is 

use 

list (object) 
where 

obj is elm; 
eqobj is eqelm; 
end objlist; 



spec classlist 
is 

use 

list ( ob jec tela ss) 
where 

class is elm; 
eqelass is eqelm; 
end classlist; 
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/* database part */ 



spec dblist 
is 

use 

list (database) 
where 

db is elm; 
eqdb is eqelm; 
end dblist; 



spec typing 
is 

extend 

boolean , 
natural , 
integer , 
character , 
str . chart ype , 
intensity , 
pointcolor , 
point , 
rectangle , 
imageform, 
pntblktrans , 
iconfont , 
identifiers , 
memaddress , 
regaddress , 
stkaddress , 
dregaddress , 
monitorattribute , 
files , 

operatorclasses , 
instructiontype , 
pidlis t , 
pidsetlist , 
vallist , 
valsetlist , 
proplist , 
propsetlist , 
pvallist , 
pvalsetlis t , 
ob j 1 i s t , 
classlist 
dblist 
with 

sort 

type; 
val ; 



/* database part */ 



/* database part */ 
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primitive 

op 

typingopers (bool) ; 
typingopers (nat) ; 
typingopers ( int) ; 
typingopers (char) ; 
typingopers ( str . char ) ; 
typingopers (intens) ; 
typingopers ( color) ; 
typingopers (pnt) ; 
typingopers (ret) ; 
typingopers ( form) ; 
typingopers (ptblt) ; 
typingopers (font) ; 
typingopers (memid) ; 
typingopers (regid) ; 
typingopers ( stkid) ; 
typingopers (dregid) ; 
typingopers (fid) ; 
typingopers (memaddr ) ; 
typingopers (regaddr) ; 
typingopers (stkaddr) ; 
typingopers (dregaddr) ; 
typingopers (mattribute) ; 
typingopers (file) ; 
typingopers (mop) ; 
typingopers (dop) ; 
typingopers (top) ; 
typingopers (qop) ; 
typingopers ( sop) ; 
typingopers (oop) ; 
typingopers (rop) ; 
typingopers (bop) ; 
typingopers (instr) ; 

typingopers ( pidlist . 1st) ; /* database part */ 

typingopers ( pidsetlist . Is t) ; 

typingopers (vallist . 1st ) ; 

typingopers (valsetlist . 1st ) ; 

typingopers (proplist . 1st) ; 

typingopers (propsetlist . 1st) ; 

typingopers (pvallist . 1st) ; 

typingopers (pvalsetlist . 1st) ; 

typingopers (obj list . 1st) ; 

typingopers (classlist. 1st) ; 

typingopers (dblist. 1st) ; /* database part */ 

hidden 
op 

whattype : val -*• type; 
eqtype: type, type -*■ bool; 
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axiom 

typingaxioms (bool) ; 
typingaxioms (nat) ; 
typingaxioms ( int) ; 
typingaxioms ( char ) ; 
typingaxioms ( str . char) ; 
typingaxioms ( intens) ; 
typingaxioms (color) ; 
typingaxioms (pnt) ; 
typingaxioms (ret) ; 
typingaxioms ( form) ; 
typingaxioms (ptblt) ; 
typingaxioms ( font) ; 
typingaxioms (memid) ; 
typingaxioms ( regid) ; 
typingaxioms ( stkid ) ; 
typingaxioms (dregid) ; 
typingaxioms ( fid ) ; 
typingaxioms (memaddr) ; 
typingaxioms ( regaddr) ; 
typingaxioms ( stkaddr) ; 
typingaxioms (dregaddr) ; 
typingaxioms (mattribute) ; 
typingaxioms ( file) ; 
typingaxioms (mop) ; 
typingaxioms ( dop) ; 
typingaxioms ( top) ; 
typingaxioms (qop) ; 
typingaxioms ( sop) ; 
typingaxioms (oop) ; 
typingaxioms ( rop) ; 
typingaxioms (bop) ; 
typingaxioms ( ins tr) ; 

typingaxioms ( pidlist . 1st) ; /* database part */ 

typingaxioms (pidsetlist . 1st) ; 

typingaxioms (vallist . 1st) ; 

typingaxioms (valsetlist . Is t) ; 

typingaxioms (proplist . 1st) ; 

typingaxioms ( propsetlist . 1st ) ; 

typingaxioms ( pvallist . 1st) ; 

typingaxioms (pvalsetlist . 1st) ; 

typingaxioms (obj list . 1st) ; 

typingaxioms (classlist . 1st) ; 

typingaxioms (dblist . 1st) ; /* database part */ 

equivrel ( eqtype , type ) ; 
end extend; 
end typing; 
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spec operators 
is 

extend 

operatorclasses , 
typing 
with 

primitive 

op 

boolnot: ■+ mop; 
booland: -»■ dop ; 
boolor: -> dop; 
natpred: mop; 

natsucc: -»■ mop; 
natsum: -* dop; 
natsub; -*■ dop; 
nateq: -> rop; 
natgt: -* rop; 
natlt : -* rop; 
intpred: -> mop; 
intsucc: mop; 

intabs: -* mop; 
intntoi: -> mop; 
intiton: -*• mop; 
intsum: -> dop; 
intsub: -*■ dop; 
intmlt: -* dop; 
intdiv: -*■ dop; 
intmod: dop; 

inteq: rop; 

intgt: -> rop; 
intlt : ■+ rop; 
chareq: -*■ rop; 
chargt: rop; 

charstrlen: -*■ mop; 
charmakestr: -> mop; 
charheadstr: mop; 

chartailstr: ->• mop; 
charcatstr: dop; 

str. chareq: ->■ rop? 
str. chargt: -> rop; 
intenspred: -*■ mop; 
intenssucc: -> mop; 
intenssum: -> dop; 
intenssub: -*• dop; 
intenseq : rop; 

intensgt: ■+• rop; 
colorredcompnt : mop; 

colorgrncompnt : -* mop; 
colorblucompnt : -*■ mop; 
colordef: -> top; 
coloreq: -*■ rop; 
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pntxcord : -* mop 
pntycord : -> mop; 
pntloc : -> dop; 
pntoffset; ->■ top; 
pnteq : -*■ rop; 
pntgt: -> rop; 
pntlt: -+ rop; 
pntge: -> rop; 
pntle: -> rop; 
rctorigin: -> mop; 
rctcorner: -> mop; 
rctxdim: mop; 

rctydim : -> mop ; 
rctarea: -*■ dop; 
ret in: -> dop; 
retdis j : ■+ dop; 
rctint: dop; 

retput: dop; 

rctshift: -*■ top; 
forminit: -»■ mop; 
formfarea: -> mop; 
formgetcolor : -> dop; 
formfill: -> dop; 
formsetcolor : -»■ top; 
forminv: -> top; 
fontinit: -»■ map; 
fontret : -> mop; 
fontlen: -*■ mop; 
fontspmap: -> dop; 
fontpsmap: dop; 

font in: -> dop; 
fontdel: -*■ dop; 
fontget: dop; 

fontset: -> top; 
fontoffset: -> qop; 
ptbltgetsrct : -»■ mop; 
ptbltgetdrct : -> mop; 
ptbltgetcrct : -*■ mop; 
ptbltgetrule : -> mop; 
ptbltsetsrct : -»■ dop; 
ptbltsetdrct : -> dop; 
ptbl tsetcrct : -»■ dop; 
ptbl tsetrule : dop; 

ptbltcopy: qop; 

ptbltdrawline : sop; 

ptbltfont: -* sop; 
ptbltfontinv : -> oop; 

pidlist . eqls t : ->■ rop; /* database part */ 

pidsetlist . makenewls t : -*■ mop; 

pidsetlist . unlst : dop; 

pidsetlist . intlst : dop; 

pidsetlist . memblst : rop; 
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mop ; 



pidsetlist . eqlst : -> rop; 
vallist . eqlst : -> rop; 
valsetlist .makenewlst : -> 
valsetlist . unlst : -> dop; 
valsetlist . intlst : -* dop; 
valsetlist . memblst : -> rop; 
valsetlist . eqlst : -* rop; 
proplis t . f irstls t : -> mop; 
proplist . restlst ; -> mop; 
proplist . catlst : -> dop; 
proplis t . eqlst ; -> rop; 
propsetlist .makenewlst : -* mop; 
propsetlist . sof irs tlst : -> mop; 
propsetlist . unlst : -> dop; 
propsetlist . intis t : -> dop; 
propsetlist .memblst : -* rop; 
propsetlist . eqlst : -* rop; 
pvallist . f irstlst : -> mop; 
pvallist . restlst : -> mop; 
pvallist . catlst : -> dop; 
pvallist .memblst : -> rop; 
pvallist . eqlst : -> rop; 
pvalsetlist .makenewlst : -> mop; 
pvalsetlist . sof irs tlst ; -> mop; 
pvalsetlist . unlst : -> dop; 
pvalsetlist . intis t : -> dop; 
pvalsetlist .memblst : -> rop; 
pvalsetlist . eqlst : -> rop; 
obj list . makenewlst : -> mop; 
obj list . sof irs tlst : -> mop; 
obj list . getlst : -> dop; 
obj list . eqlst : -> rop; 
obj list .memblst : rop; 

classlist .makenewlst : -> mop; 
classlist . sof irs tlst : -> mop; 
classlist . unlst : -> dop; 
classlist . intis t : -> dop; 
classlist . catlst : -> dop; 
classlist . deist : -> dop; 
classlist .memblst : -> rop; 
classlist . eqlst : -> rop; 
db list .makenewlst : -> mop; 
dblist . sof irstlst : -> mop; 
dblis t . catlst : -> dop; 
dblist . deist : -> dop; 
dblist . intlst : -> dop; 
dblist .modlst : -> top; 

dblist .memblst : -> rop; /* database part */ 

isbool: -> bop; 
isnat: -> bop; 
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isint: -»■ bop; 
is char: -> bop; 
isstr.char: -> bop; 
isintens : -* bop; 
iscolor: ->- bop; 
ispnt: -*■ bop; 
isrct: -> bop; 
isform: -*■ bop; 
isptblt: -*• bop; 
isfont: -> bop; 
ismemid: bop; 

isregid: -> bop; 
isstkid: ■+ bop; 
isdregid: -* bop; 
isfid: -*• bop; 
ismemaddr: bop; 

isregaddr: -*■ bop; 
isstkaddr: bop; 

isdregaddr : -* bop; 
is file: ■+ bop; 
ismop: -*■ bop; 
isdop: ■+ bop; 
istop: bop; 

isqop: -*■ bop; 
issop: bop; 

isoop: -> bop; 
isrop: bop; 

isbop: -»■ bop; 
isinstr: bop; 

ispidlist . 1st : -»■ bop; /* database part 

ispidsetlist . Is t : bop; 

isvallist . 1st : bop; 

isvalsetlist . 1st : -»■ bop; 

isproplist. 1st : ■+ bop; 

ispropsetlist. 1st : -> bop; 

ispvallist . 1st : ■+ bop; 

ispvalsetlist . 1st : -* bop; 

isob j list . Is t : -*■ bop; 

isclasslist .1st: -»■ bop; 

isdblist . 1st : ■+ bop; /* database part 

hidden 
op 



applymop 

applydop 

applytop 

applyqop 

applysop 

applyoop 

applyrop 

applybop 



mop,val val; 

dop,val,val -> val; 

top , val , val , val ->■ val; 

qop , val , val , val , val val; 

sop , val , val , val , val , val , val -*• val; 

oop, val , val , val , val , val ,val ,val , val -»■ 

rop,val,val val; 

bop, val val; 



V 



V 



val ; 
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axiom 

applymop (boolnot ( ) , v) = valofbool (not ( 
atomofbool (v) ) ) ; 

applydop (booland ( ) , vl , v2) = valofbool (and (. 

atomofbool (vl) , atomofbool (v2) ) ) ; 

applydop (boolor () ,vl ,v2) = valofbool (or ( 

atomofbool (vl) , atomofbool (v2) ) ) ; 

applymop (natpred () ,v) = valof nat (prednat ( 
atomofnat ( v) ) ); 

applymop (natsucc () ,v) = valof nat ( succnat ( 
atomofnat (v) ) ) ; 

applydop (natsum (), vl , v2) = valof nat ( sumnat ( 
atomofnat (vl) , atomofnat (v2 ) ) ) ; 

applydop (natsub (), vl , v2 ) = valof nat (subnat ( 
atomofnat (vl) , atomofnat (v2 ) ) ) ; 

applymop (intpred () ,v) = valof int (predint ( 
atomof int (v) ; 

applymop (intsucc () ,v) = valof int ( succint ( • 
atomof int ( v) ; 

applymop ( intabs (), v) = valof int ( absint ( 
atomof int ( v) ; 

applymop (intntoi (), v) = valof int (ntoi ( 
atomofnat (v) ) ) ; 

applymop ( intiton (), v) = valof nat ( iton ( 
atomof int (v) ) ); 

applydop ( intsum (), vl , v2) = valof int (sumint ( 

atomof int (vl) , atomof int (v2) ) ) ; 

applydop ( intsub (), vl , v2) = valof int ( sub int ( 
atomof int (vl) ,atomof int (v2) ) ) ; 

applydop ( intmlt () ,vl ,v2) = valof int (mltint ( 

atomof int (vl ) , atomof int (v2) ) ) ; 

applydop (intdiv () ,vl ,v2) = valof int (divint ( 

atomof int (vl) , atomof int (v2 ) ) ) ; 

applydop ( intmod (), vl , v2) = valof int (modint ( 

atomof int (vl) , atomof int (v2 ) ) ); 

applymop (chars trlen (), v) = valof nat ( lenstr . char ( 
atomof str . char (v) ) ); 

applymop (charmakestr (), v) = valof str . char ( 
makestr . char ( atomof char (v) ) ); 

applymop (charheadstr (), v) = valof char (headstr . char ( 
atomof str . char (v) ) ); 

applymop (chartailstr () ,v) = valof str . char ( 

tailstr . char ( atomof str . char (v) ) ) ; 

applydop (charcatstr () ,vl , v2 ) = valof str . char ( 
cats tr . char (atomof str . char (vl) , 
atomof str . char (v2) 

) ) ; 

applymop ( intenspred (), v) = valof intens ( 
predintens ( atomof intens ( v) ; 
applymop ( intenssucc (), v) = valofintens ( 
succintens (atomof intens (v) ; 
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applydop (intenssum( ) , vl,v2) = valofintensC 
sumintens (atomof intens (vl) , 
atomof intens ( v2 ) 

) ) ; 

applydop (intanssub () , vl , v2 ) = valofintensC 
subintens (atomof intens (vl) , 
atomof intens (v2) 

) ) ; 

applymop Ccolorredcompnt ( ) , v) = valofintensC 
redcompnt ( atomof color (v)) ); 

applymop (colorgrncompnt (), v) = valof intens ( 
grncompnt (atomof color (v) ) ) ; 

applymop (colorblucompnt () ,v) = valof intens ( 
blucompnt ( atomof color (v) ) ); 

applytop ( colordef ( ) , vl , v2 , v3) = valofcolor( 
defcolor (atomof intens (vl) , 
atomof intens (v2 ) , 
atomofintens (v3.) 

) ) ; 

applymop (pntxcord () ,v) = valof int (xcord ( 

atomofpnt(v) ) ) ; 

applymop ( pntycord (), v) = valof int (y cord ( 

atomof pnt (v) ) ) ; 

applydop (pntloc () ,vl ,v2) = valofpnt ( locpnt ( 

atomof int (vl) , atomof int (v2 ) ) ); 

applytop (pntoff set () ,vl , v2 ,v3) = valofpnt ( 
of f setpnt (atomofint (vl) , 
atomofpnt ( v2) , 
atomofpnt ( v3 ) 

) ) ; 

applymop (rctorigin (), v) = valof pnt (origin ( 
atomof ret ( v) ) ); 

applymop ( rctcorner (), v) = valof pnt (corner ( 
atomofret (v) ) ) ; 

applymop (rctxdim( ) ,v) = valof int (xdimret ( 
atomof ret (v) ) ); 

applymop ( rctydim (), v) = valof int (ydimret ( 
atomof ret (v) ) ); 

applydop (rctarea () ,vl ,v2) = valof ret (area ( 

atomofpnt (vl) , atomofpnt (v2) ) ) ; 

applydop (ret in () ,vl,v2) = valofbool ( inret ( 

atomofpnt (vl) , atomof ret (v2) ) ) ; 

applydop (retdisj () ,vl ,v2) = valofbool (disj ret ( 

atomof ret (vl) , atomof ret (v2) ) ) ; 

applydop (rctint (), vl , v2) = valofrct ( intsetret ( 

atomofret (vl) ,atomofrct (v2) ) ); 

applydop (retput () ,vl ,v2) = valofrct (putret ( 

atomofpnt (vl) , atomof ret (v2 ) ) ) ; 

apply top (rctshift (), vl , v2 ,v3 ) = valof ret ( shif tret ( 

atomofint ( vl) , 
atomof int (v2 ) , 
atomof int (v3 ) , 

) ) ; 
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applymop ( forminit ( ) , v) = valof f orm ( initf orm ( 
atomofrct(v) ) ) ; 

applymop (.formf area (), v) = valof ret (f area ( 
atomof form ( v) ) ); 

applydop ( f ormgetcolor ( ) , vl , v2) = valofcolor( 

getcolor (atomofpnt (vl) , atomof form (v2 ) ) ) ; 

applydop (formfill (), vl ,v2) = valof form ( filiform ( 
atomof color ( vl) , atomof form(v2) ) ) ; 

applytop ( formsetcolor ( ) , vl , v2 , v3) = valofform( 
setcolor (atomofpnt (vl) , 
atomofpnt (v2) , 
atomofpnt ( v3 ) 

) ) ; 

applytop ( forminv () , vl ,v2 ,v3) = valofform( 
invform (atomof color ( vl) , 
atomof color (v2 ) , 
atomofcolor (v3) 

) ) ; 

applymop (fontinit (), v) = valof font ( initfont ( 
atomofrct(v) ) ) ; 

applymop ( fontret (), v) = valofrct ( rctfont ( 
atomof font (v) ) ) ; 

applymop ( fontlen (), v) = valofnat ( lenfont ( 
atomof font ( v) ) ); 

applydop ( fontspmap (), vl , v2) = valof pnt ( spmap ( 
atomof ret (vl ) , atomofpnt (v2) ) ) ; 

applydop (fontpsmap (), vl ,v2) = valofpnt (psmap ( 

atomofret ( vl) , atomofpnt (v2) ) ) ; 

applydop ( fontin (), vl , v2 ) = valofbool ( infont ( 
atomofnat ( vl) , atomof font (v2) ) ) ; 

applydop (fontdel (), vl , v2). = valof font ( delfont ( 
atomofnat (vl) ,atomoffont (v2) ) ) ; 

applydop ( fontgetfont (), vl , v2 ) = valof form (getfont ( 
atomofnat (vl ) , atomof font (v2 ) ) ) ; 

applytop ( fontset (), vl , v2 , v3 ) = valof font ( setfont ( 
atomof form (vl) , 
atomofnat (v2 ) , 
atomof font ( v3) 

) ) ; 

applyqop ( fon toff set (), vl , v2 , v3 , v4 ) = valofpnt ( 
of fsetfont (atomofint ( vl) , 
atomof int (v2 ) , 
atomof font (v3 ) , 
atomofpnt ( v4) 

) ) ; 

applymop (ptbltgetsrct (), v) = valofrct (getsret ( 
atomofptblt ( v) ) ) ; 

applymop (ptbltgetdrct (), v) = valofrct ( getdret ( 
atomofptblt (v) ) ) ; 
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applymop (ptbltgetcrct ( ) , v) = valof ret (getcrct ( 
atomofptblt ( v) ) ); 

applymop (ptbl tgetrule () ,v) = valof nat (getrule ( 
atomofptblt (v) ) ) ; 

applydop (ptbltsetsrct ( ) , vl , v2) = valofptblt(. 

setsret (atomofret (vl) , atomofptblt (v2 ) ) ) ; 

applydop (ptbltsetdrct () ,vl ,v2) = valofptblt( 

setdret (atomofret (vl) , atomofptblt (v2) ) ) ; 

applydop (ptbl tsetcrct (_) ,vl ,v2) = valofptblt( 

setcrct (atomofret (vl) , atomofptblt (v2) ) ) ; 

applydop (ptbltsetrule () , vl , v2 ) = valofptblt( 

setrule (atomofnat (vl) , atomofptblt (v2) ) ) ; 

applyqop (ptbltcopy ( ) , vl , v2 , v3 , v4) = valofform( 
copyblt (atomofptblt (vl) , 
atomof f orm ( v2) , 
atomoff orm(v3) , 
atomof form (v4 ) 

) ) ; 

applysop (ptbltdrawline ( ) , vl , v2 , v3 , v4 , v5 , v6 ) = 
valofform(drawline (atomofpnt (vl) , 

atomofpnt (v2) , 
atomofblt (v3) , 
atomof form (v4 ) , 
atomof form (v5) , 
atomof form (v6) 

) ) ; 

applysop (ptbltfont ( ) , vl , v2 , v3 , v4 , v5 , v6 ) = 
valof form (copyfont (atomofpnt (vl) , 

atomofptblt (v2) , 
atomofnat ( v3 ) , 
atomof font (v4 ) , 
atomof form (v5 ) , 
atomof form (v6 ) , 

) ) ; 

applyoop ( ptbltf ontinv ( ) , vl , v2 , v3 , v4 , v5 , v6 , v7 , v8 ) = 

valofform (inveopyfont (atomof color ( vl) , 

atomof color (v2 ) , 
atomofpnt ( v3 ) , 
atomof ptblt (v4 ) , 
atomof nat (v5 ) , 
atomof font (v6) , 
atomof form (v7 ) , 
atomof form ( v8) 

)) ; 

applymop(pidsetlist .makenewlst () ,v) = 

valof pidsetlist (pidsetlist . makenewlst ( 
atomofpidlist ( v) 

) ) ; /* database part */ 

applydop (pidsetlist . unlst ( ) ,vl,v2) = 

valof pidsetlist (pidsetlist. unlst ( 
atomof pidsetlist (vl) , 
atomof pidsetlis t (v2 ) 

) ) ; 
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applydop (pidsetlist . intlst ( ) ,vl,v2) = 

valof pidsetlist (pidsetlist. intlst ( 
atomofpidsetlist (vl) , 
at omof pidsetlist ( v2 ) 

) ) ; 

applymop ( valsetlist .makenewlst ( ) ,v) = 

valofvalsetlist (valsetlist .makenewlst ( 
atomof vallist (v) ) ); 

applydop (valsetlist . unlst ( ) ,vl,v2) = 

valofvalsetlist ( va Is et list. un 1st ( 
atomofvalsetlist ( vl) , 
atomof valsetlist (v2 ) 

) ) ; 

applydop (valsetlist . intlst ( ) ,vl,v2) = 

atomofvalsetlist (valsetlist . intlst ( 
atomof valsetlist (vl) , 
atomofvalsetlist (v2) 

)); 

applymop (proplist . firstlst () ,v) = valof pidlist ( 
proplist . firstlst (atomofproplist (v) ) ) ; 

applymop (proplist . restlst () ,v) = valofvalsetlist ( 
proplist . restlst (atomofproplist ( v) ) ); 

applydop ( proplist . catlst () ,vl ,v2 ) = valof proplist ( 
proplist . catlst (atomofpidlist (vl) , 

atomofvalsetlist (v2 ) 

) ) ; 

applymop (propsetlist .makenewlst ( ) ,v) = 

valofpropsetlist (propsetlist .makenewlst ( 
atomof proplist (v) ) ) ; 

applymop (propsetlist . sofirstlst ( ) ,v) = 

valof pidsetlist (propsetlist . so firstlst ( 
atomof propsetlist (v) ) ) ; 

applydop (propsetlist . unlst ( ) ,vl,v2) = 

valofpropsetlist (propsetlist .unlst ( 
atomof propsetlist (vl ) , 
at omof propsetlist (v2 ) 

) ) ; 

applydop (propsetlist . intlst ( ) ,vl,v2) = 

valofpropsetlist (propsetlist . intlst ( 
atomof propsetlist (vl) , 
atomof propsetlist ( v2) 

) ) ; 

applymop (pvallist . firstlst (), v) = valof pidlist ( 
pvallist . firstlst (atomofpvallist (v) ) ) ; 

applymop (pvallist . restlst () ,v) = valofvallist ( 
pvallist . restlst ( atomofpvallist ( v) ) ); 

applydop (pvallist .catlst () ,vl , v2) = valofpvallist ( 
pvallist .catlst (atomofpidlist (vl) , 

atomof vallist (v2) 



) ) 
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applymop (pvalsetlist .makenewlst ( ) , v) = 

pvalsetlist .makenewlst (atomof pval list (v) ) ) 

applymop (pvalsetlist . sofirstlst ( ) ,v) = 

valofpidsetlist (pvalsetlist. sofirstlst ( 
atomofpvalsetlis t ( v) ) ) ; 

applydop (pvalsetlist . unlst ( ) ,vl,v2) = 

valofpvalsetlist (pvalsetlist , unlst ( 
atomofpvalsetlis t (vl) , 
atomofpvalsetli st ( v2) 

) ) ; 

applydop ( pvalsetlist . intlst ( ) ,vl,v2) = 

valofpvalsetlist (pvalsetlist. intlst ( 
atomofpvalsetlist (vl) , 
atomofpvalsetlist ( v2 ) 

) ) ; 

applymop (obj list .makenewlst () ,v) = valofob j list ( 

obj list . makenewlst (atomofpvalsetlist (v) ) ) ; 

applymop (objlist. makenewlst () ,v) = valofpvalsetlist ( 
obj list .makenewlst (atomofobj list (v) ) ) ; 

applymop (obj list , sofirstlst () ,v) = valofpidsetlist ( 
obj list . sofirstlst (atomofobj list (v) ) ) ; 

applydop (obj list . getlst (), vl , v2 ) = valofvallist ( 
obj list . getlst (atomofobj list ( vl) , 

atomofpidlist ( v2 ) , 

)); 

applymop ( classlist .makenewlst () ,v) = 

valof classlist (classlist .makenewlst ( 
atomofpidsetlist ( v) ) ) ; 

applymop ( classlist . sofirst . 1st ( ) ,v) = 

valofpidsetlist (classlist. sofirstlst ( 
atomof classlist ( v) ) ); 

applydop ( classlist . unlst (), vl , v2 ) = valof classlist ( 

classlist . unlst ( atomof classlis t ( vl) , 

atomof classlist ( v2 ) 

) ) ; 

applydop (classlist . intlst ( ) ,vl,v2) = 

valofclasslist( classlist. intlst ( 
atomof classlist (vl) , 
atomof classlist ( v2) 

) ) ; 

applydop ( classlist . catlst ( ) ,vl,v2) = 

valofc lass list (classlist. catlst ( 
atomof classlist (vl ) , 
atomofobj list (v2) 

) ) ; 

applydop ( classlist . deist ( ) ,vl,v2) = 

valof classlist (classlist. deist ( 
atomofobj list (vl ) , 
atomof classlist ( v2) 

) ) ; 
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applymop (dblist .makenewlst Q , v) = 

valofdblist (dblist .makenewlst (. 
atomof classlist (v) ) ) ; 

applymop (dblist . sofirstlst () ,v) = 

valofpidsetlist (dblist . sofirstlst ( 
atomofdblist (v) ) ); 

applydop (dblist . catlst (), vl , v2 ) = valofdblist( 
dblist . catlst (atomof dblist (vl ) , 

atomof classlist (v2) 

).) ; 

applydop (dblist . deist () , vl , v2 ) = valofdblist( 

dblist . deist (atomof classlist (vl) , 
atomofdblist (v2) 

) ) ; 

applydop (dblist . intlst ( ) ,vl,v2) = 

valof pvalsetlist (dblist. intlst ( 
atomof dblist (vl) , 
atomof classlist (v2) 

) ) ; 

applydop (dblist . retobj 1st ( ) ,vl,v2) = 

valof obj list (dblist. retobj 1st ( 
atomof dblist (vl ) , 
atomofpvallist (v2) 

) ) ; 

applytop (dblist .modlst ( ) ,vl,v2,v3) = 
valofdblist (dblist , modlst ( 
atomof dblist (vl ) , 
atomofobj list (v2) , 
atomofpvallist (v3) 

) ) ; /* database part */ 

relop (nat , eq) ; 

relop (nat , gt) ; 

relop ( nat , It ) ; 

relop (int ,eq) ; 

relop ( int , gt) ; 

relop ( int , It) ; 

relop (char , eq) ; 

relop (char,gt) ; 

relop (str. char ,eq) ; 

relop (str . char , gt) ; 

relop ( intens , eq) ; 

relop ( intens , gt) ; 

relop ( intens , It) ; 

relop (colorkeq) ; 

relop (pnt , eq ) ; 

relop (pnt , gt) ; 

relop (pnt, It) ; 

relop (pnt , ge) ; 

relop ( pnt , le) ; 
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relop (pidlist , eqlst) ; 

relop (pidsetlist,eqlst) ; 

relop (vallist , eqlst) ; 

relop (valsetlist , eqlst) ; 

relop (proplist , eqlst) ; 

relop (propsetlist , eqlst) ; 

relop (pvallist , eqlst) ; 

relop ( pvalsetlist , eqlst ) ; 

relop (obj list , eqlst) ; 

relop (classlist,eqlst) ; 

relop (dblist, eqlst) ; 

relop (pidsetlist ,memblst) ; 

relop (valsetlist ,memblst). ; 

relop (propsetlist ,memblst) ; 

relop ( pvallist ,memblst) ; 

relop (pvalsetlist ,memblst) ; 

relop (classlist ,memblst) ; 

relop (dblist ,memblst) ; 

isops (bool) ; 

isops (nat) ; 

isops ( int ) ; 

isops ( char) ; 

isops ( str . char ) ; 

isops ( intens ) ; 

isops (color) ; 

isops (pnt ) ; 

isops (ret) ; 

isops ( form) ; 

isops (ptblt) ; 

isops ( font ) ; 

isops (memid) ; 

isops ( regid) ; 

isops ( stkid) ; 

isops (dregid) ; 

isops (fid) ; 

isops (memaddr) ; 

isops ( regaddr) ; 

isops ( stkaddr) ; 

isops (dregaddr) ; 

isops ( file) ; 

isops (mop) ; 

isops ( dop) ; 

isops ( top) ; 

isops (qop) ; 

isops ( sop) ; 

isops (oop) ; 

isops ( rop) ; 

isops (bop) ; 

isops ( instr) ; 



/* database part */ 



/* database part */ 



234 



isops (pidlist. 1st). ; 
isops (pidsetlist . 1st). ; 
isops (vallist. 1st) ; 
isops (valsetlist. 1st) ; 
isops (proplist . 1st) ; 
isops (propsetlist . 1st) ; 
isops (pvallist . 1st ) ; 
isops (pvalsetlist .1st) ; 
isops (obj list . 1st) ; 
isops (classlist . 1st) ; 
isops (dblist.lst) ; 
end extend; 
end operators; 



/* database part */ 



/* database part */ 



spec instructions 
is 

extend 

natural , 
integer, 
memaddress , 
regaddress , 
stkaddress , 
dregaddress , 
operatorclasses , 
instructiontype , 
typing, 
qaddress 
with 

primitive 

op 

org: -+ instr; 

extern: -*■ instr; 

globl: instr; 

mbegin : -> instr; 

mend: -»■ instr; 

offst: int,regaddr instr; 

link: regaddr,nat ■+ instr; 

unlink: regaddr,nat -* instr; 

getdwin: dregaddr , regaddr instr; 

setdwin: regaddr , dregaddr -> instr; 

getmtr: mattribute , regaddr -»■ instr; 

setmtr: mattribute , regaddr -*■ instr; 

modads : mop, regaddr -> instr; 

monad: mop , regaddr , regaddr ->■ instr; 

monadi: mop, val , regaddr -»■ instr; 

dyads: dop , regaddr , regaddr -* instr; 

dyadsi : dop , val , regaddr instr; 

dyad: dop , regaddr , regaddr , regaddr -* instr; 

dyadi : dop , val , regaddr , regaddr -»■ instr; 
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triads: top , regaddr , regaddr , regaddr instr; 
triadsi: top , val ; regaddr , regaddr instr; 

triad: top , regaddr , regaddr , regaddr , regaddr -> instr; 
triadi : top , val , regaddr , regaddr , regaddr -> instr; 
quads: qop , regaddr , regaddr , regaddr , regaddr -* instr; 
quad : qop , regaddr , regaddr , regaddr , regaddr , 
regaddr -»■ instr; 

sexads : sop , regaddr , regaddr , regaddr , regaddr , 
regaddr , regaddr -»■ instr; 
sexad : sop , regaddr , regaddr , regaddr , regaddr , 
regaddr , regaddr , regaddr -»■ instr; 
octads : sop , regaddr , regaddr , regaddr , regaddr , 

regaddr , regaddr , regaddr , regaddr -> instr; 
octad : sop , regaddr , regaddr , regaddr , regaddr , regaddr , 
regaddr , regaddr , regaddr , regaddr ■+ instr; 
movi m: val ; memaddr -*■ instr; 
movi_pcr: val,int -»■ instr; 
movi_r: val, regaddr -*■ instr; 
movi_ri : val, regaddr instr; 
movi_rid: val , regaddr , int -»■ instr; 
movi_ridn: val , regaddr , nat , int -»■ instr; • 
mov_m_m: memaddr ,memaddr -*■ instr; 
mov_m_r: memaddr , regaddr -> instr; 
mov_m_ri : memaddr , regaddr -> instr; 
mov_m_rid: memaddr , regaddr , int -> instr; 
mov_m_ridn: memaddr , regaddr , nat , int -»■ instr; 
mov_m_d: memaddr , dregaddr ->■ instr; 
mov_pcr_pcr: int, int instr; 
mov_pcr_r: int, regaddr ■> instr; 
mov_pcr_ri : int, regaddr instr; 
mov_pcr_rid: int , regaddr , int -> instr; 
mov_pcr_ridn : int , regaddr , nat , int -»■ instr; 
mov_pcr_d: int, dregaddr instr; 
mov_r_m: regaddr , memaddr -+ instr; 
mov_r_pcr: regaddr, int -> instr; 
mov_r_r : regaddr , regaddr instr; 
mov_r_ri: regaddr , regaddr instr; 
mov_r_rid: regaddr , regaddr , int -»■ instr; 
mov_r_ridn: regaddr , regaddr , nat , int -> instr; 
mov_r_d: regaddr , dregaddr instr; 
mov_ri_m: regaddr , memaddr -> instr; 
mov_ri_pcr: regaddr, int ->■ instr; 
mov_ri_r: regaddr , regaddr -> instr; 
mov_ri_ri : regaddr , regaddr instr; 
mov_ri_rid: regaddr , regaddr , int -*■ instr; 
mov_ri_ridn: regaddr , regaddr , nat , int -»■ instr; 
mov_ri_d: regaddr , dregaddr -*■ instr; 
mov_rid_m: regaddr , int , memaddr ->■ instr; 
mov_rid_pcr: regaddr , int , int ■> instr; 
mov_rid_r: regaddr , int , regaddr instr; 
mov_rid_ri : regaddr , int , regaddr ->■ instr; 
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mov_rid_rid: regaddr , int , regaddr , int -*■ instr; 
mov_rid_ridn : regaddr , int , regaddr , nat , int -> instr; 
mov_rid_d: regaddr , int , dr egaddr -»■ instr; 
mov_ridn_m: regaddr , nat , int , memaddr instr; 
mov_ridn_pcr ; regaddr , nat , int , int -*• instr; 
mov_ridn_r: regaddr , nat , int , regaddr -> instr; 
mov_ridn_ri: regaddr , nat , int , regaddr -> instr; 
mov_ridn_rid : regaddr , nat , int , regaddr , int -> instr; 
mov_ridn_ridn : regaddr , nat , int , regaddr , int , int -> 

instr ; 

mov_ridn_d: regaddr , nat , int , dregaddr -> instr; 

mov_d_m: dregaddr ,memaddr instr; 

mov_d_pcr: dregaddr , int -> instr; 

mov_d_r: dregaddr , regaddr -> instr; 

mov_d_ri ; dregaddr , regaddr instr; 

mov_d_rid: dregaddr , regaddr , int -> instr; 

mov_d_r idn : dregaddr , regaddr , nat , int -> instr ; 

mov_d_d: dregaddr , dregaddr -> instr; 

push_i : val , stkaddr -> instr; 

push_m: memaddr , stkaddr -> instr; 

push_pcr: int, stkaddr -> instr; 

push_r: regaddr , stkaddr -> instr; 

push_ri : regaddr , stkaddr -> instr; 

push_rid; regaddr , int , stkaddr -> instr; 

push_ridn: regaddr , nat , int , stkaddr -> instr; 

push_d: dregaddr , stkaddr -> instr; 

pop_x: stkaddr -> instr; 

pop_m: stkaddr , memaddr -> instr; 

pop_pcr; stkaddr, int -> instr; 

pop_r : stkaddr , regaddr -> instr; 

pop_ri : stkaddr , regaddr -> instr; 

pop_rid : stkaddr , regaddr , int -> instr; 

pop_ridn: stkaddr , regaddr , nat , int -*■ instr; 

pop_d; stkaddr , dregaddr -> instr; 

nop: -> instr; 

stop: -> instr; 

jmp: memaddr -> instr; 

jmp_i: memaddr -> instr; 

jmp_r: regaddr instr; 

bra: int -> instr; 

bra_r: regaddr -> instr; 

if: relop , regaddr , regaddr , memaddr -*■ instr; 

ifi: relop , regaddr , val , memaddr instr; 

ifte: relop, regaddr , regaddr , memaddr , memaddr -> instr; 

if tei : relop , regaddr , val , memaddr , memaddr -> instr; 

if_pcr: relop , regaddr , regaddr , int -> instr; 

ifi_pcr: relop , regaddr , val , int -> instr; 

ifte_pcr: relop , regaddr , regaddr , int , int -> instr; 

iftei_pcr: relop, regaddr , val , int , int -> instr; 

test: bop, regaddr , memaddr -> instr; 

testm: bop , memaddr , memaddr -> instr; 
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teste: bop , regaddr , memaddr ,memaddr -»■ instr; 

testme: bop , memaddr , memaddr , memaddr -»■ instr; 

test_pcr: bop , regaddr , int -► instr; 

testm_pcr: bop , memaddr , int -*■ instr; 

teste_pcr: bop , regaddr , int , int instr; 

testme_pcr: bop, memaddr , int , int ■+ instr; 

jsr: memaddr , stkaddr -»■ instr; 

jsr_i: memaddr , stkaddr -*■ instr; 

jsr_r: regaddr , stkaddr instr; 

bsr: int, stkaddr -*■ instr; 

bsr_r: regaddr , stkaddr -* instr; 

rts : stkaddr -*■ instr; 

open: stkaddr ->■ instr; 

close: stkaddr -*■ instr; 

read: stkaddr -*■ instr; 

write: stkaddr instr; 



/* 

write_i : val,qaddr instr; /* 

write_m: memaddr , qaddr ->■ instr; 
write_r: regaddr , qaddr instr; 
delete_x: qaddr -»■ instr; /* 

delete_m: qaddr -»■ instr; 
delete_r: qaddr -► instr; 
read_m: qaddr , memaddr -»• instr; /* 



read_r: qaddr , regaddr ->■ instr; 
open: val -»• instr; 
close: val instr; 

end extend; 
end instructions; 



/* 

/* 

/* 



database part */ 
write to queue */ 



delete value 
from queue */ 



read value from 
queue */ 



open database */ 
close database */ 
database part */ 



spec amstate 
is 

extend 

boolean , 
natural , 
integer, 
s tr . chartype , 
memaddress , 
regaddress , 
stkaddress , 
dregaddress , 
files , 

identifiers , 
typing , 
qaddr , 
db 
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with 

sort 

state ; 
primitive 

fetchm: memaddr , state -*■ val ; /* memory */ 

fetchr: regaddr , state -*■ val; /* register */ 

fetchd: dregaddr , state -*■ val; /* display register */ 
f etchdwin : dregaddr , state -* val; 

/* display window */ 
fetchmtr: mattribute , state -> val; 

/* monitor attribute */ 
storem: val , memaddr , state -* state; 
storer: val , regaddr , state -* state; 
stored: val , dregaddr , state -*■ state; 
storedwin: val , dregaddr , state state; 

storedmtr: val ,mattribute , state -> state; 
initam: -»■ state; /* initialize 

machine */ 

initstk: stkaddr , state state; 



topstk : 

pushstk 

popstk : 
lalloc : 

If ree : 
indir : 



infile : 
outf ile 



stkaddr , state -»■ val; 



/* initialize stack 
/* get top val of 
stack */ 

val , stkaddr , state -> state; 

/* push stack */ 



stkaddr , state state; 
nat , state ->■ memid; 



memid , state 
nat , memaddr 



state ; 
memaddr ; 



/* 

/* 

/* 

/* 



file,state -> val; 
val , file , state -*• 



/* 

state ; 



pop stack */ 
get memory block 
from heap */ 
free memroy block 
memaddr for n 
levels of 
indirection */ 
read from file */ 



V 



V 



/* 

open file : str . char , f ile, int , int , s 

/* 

closefile: file, state -*■ state; /* 



rmode : -»■ int; /* 

wmode : -*■ int; /* 

rwmode: int; /* 

openerr: -> int; /* 

openok: ->int; /* 

valdata: -> int; /* 

chardata: int; /* 

/* 

initq: qaddr, state -* state; /* 

read: qaddr, state -»■ val; /* 



write to file */ 
tate -* state; 
open file */ 
close file */ 
read mode */ 
write mode */ 
read/write mode */ 
open error */ 
open ok */ 
file ops w/ AM 
sort val data */ 
file ops w/ 
character data */ 
database part */ 
initialize queue */ 
read front value 
from queue */ 
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write: val ,qaddr, state -»• state; 

/* write to queue */ 

delete: qaddr, state -»■ state; /* delete front value 

from queue */ 

open: db , str. char , state state; 

/* open database */ 
close: db,str.char,state -* state; 

/* close database */ 
/* data base part */ 

hidden 

op 

/**************************************** 

* active - lalloc flag 

* true when memory block is allocated w/ lalloc 

* false initially and after memory block 
released with lfree 

* used to prevent offsetting into non- 
allocated memory 

*/ 

active: memid, state bool; 
axiom 

if whattype(v) != formtypeO then 
stored (v , a ,q) = undef; 
end if ; 

if whattype(v) 1= pnttypeO then 
storedwin ( v , a ,q) = undef; 

endif ; 

if whattype(v) != nattype ( ) 
then 

storemtr (v,xpixels ( ) ,q) = undef; 
storemtr (v,ypixels ( ) ,q) = undef; 
storemtr (v,hscrnsize () ,q) = undef; 
storemtr (v , vscrnsize () ,q) = undef; 
storemtr (v, intenscapbl () ,q) = undef; 

s toremtr ( v , colorcapbl ( ) , q) = undef; 
endif ; 

if whattype(v) != colortypeO then 
storemtr (v,backgnd( ) ,q) = undef; 

endif ; 

if whattype(v) != dregaddr ( ) then 
storemtr (v,dselect () ,q) = undef; 
endif ; 

topstk ( s , initstk ( s) ) = undef; 
popstk ( s , initstk (s) ) = undef; 
popstk ( s , initam ( ) ) = undef; 
stateaxioms (m,memaddr) ; 
stateaxioms ( r , regaddr) ; 
stateaxioms (d , dregaddr) ; 
stateaxioms (dwin , dregaddr ) ; 
stateaxioms (mtr ,mattribute) ; 
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topstk ( s , pushstk ( v, s , q) ) = v; 

popstk (s, pushstk (v,s,q) ) = q; 

active (m, initam () ) = false; 

active (lalloc (n ,q) ,q) = true; 

active (m, If ree (m,q) ) = false; 

act ive (m, storer ( v , a , q) ) = active(m,q); 

active (m, storem (v , a , q) ) = active(m,q); 

active (m, stored (v , a , q) ) = active(m,q); 

active (m, storedwin (v, a ,q ) ) = active(m,q); 

active (m, storexscrnsize (v , a ,q) ) = active(m,q); 

active (m, storeyscrnsize (v, a, q) ) = active (m,q) ; 

active (m, storeintenscapbl (v , a , q) ) = active(m,q); 

active (m, storecolorcapbl (v , a ,q) ) = active(m,q); 

active (m, storebackgnd (v , a ,q) ) = active(m,q); 

active (m, storedregaddr (v, a, q) ) = active (m,q) ; 

active (m, initstk (a ,q) ) = active (m,q); 

active (m, pushstk (v, a ,q) ) = active(m,q); 

active (m, popstk (a, q) ) = active (m,q); 

active (m,outfile (v, f ,q) ) = active(m,q); 

active (m, openf ile (s , f ,x,y ,q) ) = active(m,q); 

active (m, closefile ( f ,q) ) = active(m,q); 

if active (m,q) = false() then 

f etchm (of f set ( n ,m) ,q) = undef ; 
endif ; 

if active(m,q) = false() then 

storem (of f set (n ,m) ,q) = undef; 

endif ; 

if ltint ( n , ntoi (n2 ) ) = true ( ) 
then 

offset (n, off set (nl , startmemaddr ( 
lalloc ( n2 ,q) ) )) = 

offset ( 

sumint (n,nl) , 

startmemaddr (lalloc (n2,q) ) 

) ? 

else 

of f set ( n , of f set ( nl , startmemaddr ( lal loc ( n2 ,q) ) ) ) 

undef ; 

indir ( zeronat ( ) ,m) = m; 

if whattype ( f etchm ( indir ( n ,m) ,q) ) = typememaddr ( ) 
then 

indir (succnat (n) ,m) = atomofmemaddr ( 

f etchm ( indir (n ,m) ,q) ) ; 

else 

indir ( succnat ( n) ,m) = undef; 

endif ; 

openf ile ( s , f ,n ,openf ile ( s , f ,m,x ,q) ) = undef; 

closef ile ( f , openf ile ( s , f ,n ,x,q) ) = q; 

inf ile ( f , initam () ) = undef; 
inf ile ( f , close (d ,q) ) = undef; 

inf ile ( f , openf ile ( s , f ,wmode ( ) ,x, q) ) = undef; 
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outf ile (v , f , initam () ) = undef; 

outf ile (v , f , close (f ,q) ) = undef; 

outf ile (v , f , openf ile ( s , f , rmode (), x , q) ) = undef; 

outf ile ( f , openf ile ( s , f , m, chardata (), q) ) = undef; 

/* database part */ 

read (qu, initq (qu, q) ) = undef; /* qu : queue */ 

delete (qu, initam () ) = undef; 

/* q: state */ 

delete (qu, write (v ,qu, initq (qu ,q) ) ) =■ v; 

/* v: value */ 

read (qu ,write (v , qu, initq (qu , q) ) ) = v; 

delete (write (v,qu, initq () ) ) = initq(); 

delete (write (v,qu,q) ) = write (v , qu , delete (qu , q) ) ; 

if not (initq ()) = true ( ) 

then 

read (qu , write (v , qu ,q) ) = read(qu,q); 
endif ; 

active (m, initq (a ,q) ) = active (m,q); 
active (m, write (v , a , q) ) = active (m,q) ; 
active (m, delete ( a , q) ) = active(m,q); 
active (m, open ( s , d , q) ) = active (m , q) ; 

/* s : string char */ 
active (m, close ( s , d , q) ) = active (m , q) ; 

/* d: database */ 

/* database part */ 

end extend; 
end amstate; 



spec displaywindow 
is 

extend 

rectangle 

dregaddress 

with 

primitive 

op 

dwin: dregaddr -»■ ret; 
axiom 

xdimret (dwin (a) ) = [DISPLAYSIZEJ succint ( zeroint ( ) ) ; 
ydimret (dwin (a) ) = [DISPLAYSIZE]succint(zeroint()); 

origin (dwin (a) ) = atomofpnt ( f etchdwin (a ,q) ) ; 
end extend; 
end displaywindow; 
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spec am 
is 

extend 

memaddress , 

instructiontype , • 

typing, 
amstate 
with 

primitive 

op 

/**************************************** 

* prog - AM execution 

* corecursive - calls xeq 
*/ 

prog: memaddr , state -»■ state; 
hidden 
op 

/**************************************** 

* cond - implements conditionals 

* returns one of two input memaddrs 

* based on bool value 

V 

cond: val , memaddr , memaddr memaddr; 

/'k'k'k'k-k'k'k-k-k'k'k'k'k'k'k'k'k'k'k'k-k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k-k 

* xeq - corecursive function 

* calls prog 

* used for AM execution 

V 

xeq: instr , memaddr , state -* state; 
axiom 

prog(a,q) = xeq (atomof instr ( f etchm (a , q) , a , q) ) ; 
cond (valofbool (true ()), al , a2 ) = al; 
cond (valofbool ( false ()), al , a2) = a2; 
xeq (of f st ( i , r ) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

valofmemaddr (of f set ( i , atomofmemaddr ( 
fetchr (r , q) ) ) ) , 

r , 

q 

) 

) ; 

xeq ( link ( r , n) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

valofmemaddr ( startmemaddr ( lalloc (n ,q) ) ) , 

r , 

storem( 

fetchr (r ,q) , 



243 



) 



startmemaddr ( lalloc (n ,q) ,q) 



) 

) ? 

xeq (unlink (r) ,m,q) = 
prog ( 

nextmemaddr (m) , 

• lfree( 

getmemid (atomofmemaddr (f etchr (r ,q) ) ) , 

storer ( 

fetchm (atomofmemaddr ( fetchr (r , q) ) ,q) , 
r , 

q 

) 

) 

) ; 

xeq (getdwin (d , r) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

fetchdwin (d,q) , 
r , 

q 

) 

) ; 

xeq ( setdwin (r ,d) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storedwin ( 

fetchr (r ,q) , 

d, 

q 

) 

) ; 

xeq (getmtr ( t , r) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

f etchmtr ( t , q) , 
r , 

q 

) 

) ; 

xeq ( setmtr ( r , t ) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storemtr ( 

fetchr (r ,q) , 
t , • 

q 

) 
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xeq (monads (o , rl) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storer (. 

applymop ( 
o, 

f etchr (rl , q). 

) , 

rl, 

q 

) 

) ; 

xeq (monad (o ,rl , r2) ,m,ql 
prog ( 

nextmemaddr (m) , 
storer ( 

applymop ( 
o, 

f etchr (rl ,q) 

) , 
r2 , 

q 

) 

) ; 

xeq (monadi (o , v , rl) ,m,q) 
prog ( 

nextmemaddr (m) , 
storer (. 

applymop Co , v) , 
rl, 

q 

) 

) ; 

xeq (dyads (o , rl , r2) ,m,q) 
prog ( 

(nextmemaddr (m) , 
storer ( 

applydop ( 
o, 

fetchr (rl ,q) 
fetchr (r2 ,q) 

) , 
r2 , 

q 



) ; 

xeq (dyadsi (o , v , rl) ,m,q) 
prog ( 

nextmemaddr (m) , 
storer ( 
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applydop ( 
o, 
v, 

fetchr (rl , q) 

) , 
rl, 

q 

) 

) ; 

xeq (dyad (o , rl , r2 , r3) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

applydop ( 
o, 

fetchr (rl,q) , 
fetchr ( r 2 , q) 

) , 
r3 , 

q 

) 

) ; 

xeq (dyadi (o , v , rl , r 2) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

applydop ( 
o, 
v, 

fetchr (rl ,q) 

) , 
r2 , 

q 

) 

) ; 

xeq ( triads (o , rl , r2 , re) ,m,q) 
prog ( 

nextmemaddr (m) , 
storer ( 

applytop ( 
o, 

fetchr (rl ,q) , 
fetchr (r2 ,q) , 
fetchr (r3 ,q) 

) , 
r3 , 

q 

) 

) ; 
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xeq ( triadsi (0 , v, rl , r2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storer ( 

applytop ( 
o, 
v, 

f etchr Crl , q) , 
fetchr (r2 ,q) 

) , 
r2 , 

q 

) 

) ; 

xeq (triad (0 , rl , r2 , r3 , r4) ,m,q) 
prog ( 

nextmemaddr (m) , 
storer ( 

applytop ( 
o, 

fetchr ( rl , q) , 
fetchr (r2 ,q) , 
fetchr (r3 ,q) 

) , 
r4, 

q 

) 

) ; 

xeq ( triadi (o , v, rl , r2 , r3) ,m,q) 
prog ( 

nextmemaddr (m) , 
storer ( 

applytop ( 
o, 
v, 

fetchr (rl ,q) , 
fetchr (r2 ,q) 

) , 
r3 , 

q 

) 

) ; 

xeq (quads (o , rl , r2 , r3 , r4) ,m,q) 
prog ( 

nextmemaddr (m) , 
storer ( 

app!yqop( 

o, 

fetchr (rl ,q) , 
fetchr (r2 ,q) , 
fetchr (r3 ,q) , 
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f etchr (r4 , q) 



) , 

r4, 

q 

) 

) ; 

xeq (quad (o,rl,r2,r3,r4,r5) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storer ( 

applyqop ( 
o, 

fetchr ( rl , q) , 
fetchr (r2 ,q) , 
fetchr ( r3 , q) , 
fetchr ( r4 , q) 

) , 

r5, 

q 

) 

) ; 

xeq ( sexads) o,rl,r2,r3 / r4,r5,r6) ,m ,q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

applysop ( 
o, 

fetchr (rl ,q) , 
fetchr ( r2 , q) , 
fetchr (r3 ,q) , 
fetchr (r4 ,q) , 
fetchr ( r5 , q) , 
fetchr (r6 ,q) 

) , 
r6 , 

q 

) 

) ; 

xeq ( sexad (o,rl,r2,r3,r4,r5,r6,r7) ,m , q) 
prog ( 

nextmemaddr (m) , 
storer ( 

applysop ( 
o , 

fetchr ( rl , q0 , 
fetchr (r2 ,q ) , 
fetchr ( r3 , q) , 
fetchr (r4 ,q) , 
fetchr (r5 , q) , 
fetchr (r6 ,q) 
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) , 

r7, 

q 

) 

) ; 

xeq (octads (o,rl,r2,r3,r4,r5,r6,r7,r8) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storer ( 

applyoop ( 
o, 

f etchr (rl ,q) , 
f etchr (r2 ,q) , 
fetchr (r3 ,q) , 
fetchr (r4 ,q) , 
fetchr ( r5 , q) , 
fetchr (r6 , q) , 
fetchr ( r7 ,q) , 
fetchr ( r8 , q) 

) , 

r8 , 

q 

) 

) ; 

xeq (octad (o,rl,r2,r3,r4,r5,r6,r7,r8,r9) ,m,q) 
prog ( 

nextmemaddr (m) , 
storer ( 

applyoop ( 
o, 

fetchr (rl ,q) , 
fetchr (r2 ,q) , 
fetchr ( r3 ,q) , 
fetchr (r4 ,q) , 
fetchr ( r5 , q) , 
fetchr ( r6 , q) , 
fetchr ( r7 , q) , 
fetchr (r8 ,q) 

) , 

r9, 

q 

) 

) ; 

xeq (movi_m ( v,ml) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem(v,ml ,q) 

( ; 

xeq (movi_pcr (v, i) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 
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V, 

offset ( i ,m) , 

q 

) 

) ; 

xeq ( movi_r ( v , r ) , m , q ) = 
prog ( 

nextmemaddr (m) , 
storem ( 
v, 

offset ( i ,m) , 

q 

) 

) ; 

xeq ( mo vi_r ( v , r ) , m , q ) = 

prog (nextmemaddr (m) , storer ( v , r , q) ) ; 
xeq (movi_ri (v, r) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 
v, 

atomofmemaddr ( f etchr ( r , q) ) , 

q 

) 

) ; 

xeq (movi_rid( v, r ,n) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 
v, 

offset ( 
n, 

atomofmemaddr (fetchr (r ,q) ) 

) , 
q 

) 

) ; 

xeq (movi_ridn ( v, r , il , i2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 
v, 

offset ( 
i2 , 

indir ( 
il, 

atomofmemaddr (fetchr (r ,q) ) 

) 

) , 
q 

) 

) ; 
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xeq (movi_d( v,r) ,m,q) = 

prog (nextmemaddr (m) , stored (v, r,q) ) ; 
xeq ( mov_m_m (ml , m2 ) ,m,q).= 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm (ml , q), , 
m2 , 

q 

) 

) ; 

xeq (mov_m_r (ml , r) ,m,q)= 

prog (nextmemaddr (m) , storer ( f etchm (ml ,q) , r ,q) ) ; 
xeq (mov_m_ri (ml , r) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm (ml , q) , 

atomofmemaddr ( f etchr ( r , q) ) 

) 

) ; 

xeq ( mo v_m_r id ( m , 1 , r , n ) , m , q ) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm(ml ,q) , 
offset ( 
n, 

atomofmemaddr ( f etchr ( r , q ) ) 

) , 
q 

) 

) ; 

xeq (mov_m_ridn (ml,r,il,i2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm (ml , q) , 
offset ( 
ie, 

indir ( 

il ' 

atomofmemaddr (f etchr (r,q) ) 

) 

) , 
q 

) 

) ; 

xeq (mov_pcr_pcr (il, i2) ,m,q) = 
prog ( 
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nextmemaddr (m) , 
storem ( 

f etchm (of f set ( il ,m) ,q) , 
offset ( i 2 ,m) , 

q 

) 

) ; 

xeq (mov_pcr_r ( i , r ) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

fetchm (of f set (i ,m) ,q) , 
r , 

q 

) 

) ; 

xeq (mov_pcr_ri ( i , r ) ,m,q)= 
prog) 

nextmemaddr (m) , 
storem ( 

fetchm (of f set ( i ,m) ,q) , 
atomofmemaddr ( f etchr ( r , q) ) , 

q 

) 

) ; 

xeq (mov_pcr_rid ( il , r , i2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm (of f set ( il , m) ,q) , 
offset ( 
i2 , 

atomofmemaddr ( f etchr (r , q ) \ 

) , 
q 

) 

) ; 

xeq (mov_pcr_ridn (il,r,n,i2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm (of f set ( il ,m) ,q) , 
offset ( 
i2, 

indir ( 
n, 

atomofmemaddr ( f etchr ( r , q) ) 

) 

) , 

q 

) 

) ; 
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xeq (mov_m_d (ml , r) ,m,q) = 

prog (nextmemaddr (m) , stored ( fetchm (ml , q) ,r,q)) 
xeq (mov_r_m(r ,ml) ,m,q)= 

prog ( nextmemaddr (m) , storem (fetchr (r ,q) ,ml,q)) 
xeq (mov_r_pcr ( r , i) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchr (r,q) , 
offset (i ,m) , 

q 

) 

). ; 

xeq (mov_r_r (rl , r] ) ,m, q) = 

prog (nextmemaddr (m) , store r ( fetchr ( rl , q) , r2 , q) ) ; 
xeq (mov_r_ri (rl , r2) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchr (rl ,q) , 

atomofmemaddr ( fetchr ( r2 ,q) ) , 

q 

) 

) ; 

xeq (mov_r_rid (rl , r2 , n) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchr (.rl , q) , 
offset ( 
n, 

atomofmemaddr ( fetchr ( r2 , q) ) 

) , 
q 

) 

) ; 

xeq (mov_r_ridn (rl , r2 , il , i2) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchr ( rl ,q) , 
offset ( 
i2 , 

indri ( 
il, 

atomofmemaddr ( fetchr ( r2 , q) ) 

) 

) , 
q 

) 

) ; 
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xeq (mov_r_d (rl , r2) ,m,q)= 

prog (nextmemaddr (m) , stored ( fetchr ( rl ,q) , r2 ,q) ) 
xeq (mov_ri_m) r ,ml) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm (atomofmemaddr (fetchr (r ,q) ) ,q) , 
ml , 

q 

) 

) ; 

xeq (mov_ri_pcr ( r , i) , m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm (.atomofmemaddr (.fetchr (r,q) ) ,q) , 
offset ( i ,m) , 

q 

) 

) ; 

xeq (mov_ri , r (rl , rq),m,q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

fetchm (atomofmemaddr ( fetchr ( rl ,q) ) ) , 

r2 , 

q 

) 

) ; 

xeq (mov_ri_ri ( rl , r2) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm (atomofmemaddr (fetchr (rl ,q) ) ,q) , 
atomofmemaddr ( 
fetchr ( r2 , q) 

) , 

q 

) 

) ; 

xeq (mov_ri_rid) rl , r2 , n) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm (atomofmemaddr ( fetchr ( rl , q) ) ,q) , 
offset ( 
n, 

atomofmemaddr ( fetchr ( r2 , q) ) 

) , 

q 

) 

) ; 
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xeq (mov_ri_ridn ( rl , r2 , il , i2) m, q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm (atomofmemaddr ( f etchr ( rl , q) ) ,q) , 
offset ( 
i2 , 

indir ( 
il, 

a tomo'fmemaddr ( f etchr ( r 2 , q ) ) 

) 

) , 
q 

) 

) ; 

xeq (mov_ri_d (_rl , r2) ,m,q) = 
prog ( 

nextmemaddr (m) , 
stored ( 

fetchm (atomofmemaddr ( fetchr ( rl ,q) ) ) , 

r2 , 

q 

) 

) ; 

xeq (mov_rid_m (r , i ,ml) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm ( 

offset( 

i , 

atomofmemaddr (fetchr (r,q) ) 

) , 
q 

) , 
ml , 

q 

>; » 

xeq (mov_rid_pcr) r , il , i2 ) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm ( 

offset ( 

il, 

atomofmemaddr ( fetchr ( r , q) ) 

) , 
q 

) , 

of fset (i2 ,m) , 

q 
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) 

) ; 

xeq (mov_rid_r (rl , n , r2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storer ( 

f etchm ( 

offset ( 

n, 

atomofmemaddr ( f etchr (rl,q) ) 

) , 

q 

) , 
r2 , 

q 

) 

) ; 

xeq (mov_rid_ri ( rl , i , r2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

of f se t ( 

i , 

atomofmemaddr ( f etchr ( rl , J ) ) 

) , 

q 

) , 

atomofmemaddr (f etchr ( r2 ,q) ) , 

q 

) 

) ; 

xeq (mov_rid_rid (rl,il,r2,i2) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fe tchm ( 

offset ( 

il, 

atomofmemaddr ( f etchr ( rl , q) ) 

) , 

q 

) , 

offset ( 

12 , 

atomofmemaddr ( fetchr (r2 ,q) ) 

) , 

q 

) 

) ; 

xeq (mov_rid_ridn (rl,il,r2,i,2,i3) ,m,q)= 
prog ( 
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nextmemaddr (m) , 
storem ( 

f etchm ( 

offset C 

il, 

atomofmemaddr ( fetchr (rl ,q) ) 

) , 
q 

) , 

offset ( 
i3 , 

indir (. 
i2 , 

atomofmemaddr (fetchr (r2 ,q) ) 

) 

) , 
q 

) 

) ; 

xeq (mov_rid_d ( rl , n , r2) ,m,q) = 
prog ( 

nextmemaddr (m) , 
stored ( 

f etchm ( 

offset ( 
n, 

atomofmemaddr ( fetchr ( rl , q) ) 

) , 
q 

) , 
r2, 

q 

) 

) ; 

xeq (mov_ridn_m ( r ,n , i ,ml) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

offset ( 

i , 

indir ( 

n , atomofmemaddr ( fetchr ( r , q) ) 

) 

). , 
q 

) , 
q 

) 

) ; 

xeq (mov_ridn_pcr (r,n,il,i2) ,m , q) = 
prog ( 
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nextmemaddr (m) , 
storem ( 

fetchm ( 

offset ( 

11 > 

indir ( 
n, 

atomofmemaddr ( f etchr (r ,q) ) 

) 

) , 

q 

) , 

offset (i2m, ) , 

q 

) 

) ; 

xeq (mov_ridn_r (rl,il,i2,r2) ,m,q) = 
prog ( 

nextmemaddr (m) , 
storer ( 

fetchm ( 

offset ( 

12 , 

indir ( 

il/ 

atomofmemaddr ( fetchr (rl ,q) ) 

) 

) , 

q 

) , 

r2 , 

) q 

) ; 

xeq (mov_ridn_r (rl,il,i2,r2) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchm ( 

offset ( 
i2 , 

indir ( 
il/ 

atomofmemaddr ( fetchr (rl ,q) ) 

) 

) , 

q 

) / 

atomofmemaddr ( 
fetchr (r2 ,q) 

) , 

q 



) ; 
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xeq (mov_ridn_rid (rl,il,i2,r2,i3) ,m,q) 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

of f set ( 

12 , 

indir ( 
ilf 

atomofmemaddr ( f etchr ( rl , q) ) 

) 

) , 
q 

) , 

offset ( 

13, 

atomofmemaddr ( f etchr (r 2 , q) ) 

) , 
q 

) 

) ; 

xeq (mov_ridn_ridn (rl,il,i2,r,i3,i4) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

f etchm ( 

offset ( 

3 . 2 , 

indir ( 
il, 

atomofmemaddr ( f etchr ( r 1 , q) ) 

) 

) , 
q 

) , 

offset ( 

14, 

indir ( 

13 , 

atomofmemaddr (fetchr (r2 ,q) ) 

) 



q 

) 

) ; 

xeq (mov_ridn_d ( rl , il , ir , r2) ,m , q) = 
prog ( 

nextmemaddr (m) , 
stored ( 

f etchm ( 
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offset ( 

i2 , 

indir (. 
il, 

atomofmemaddr ( fetchr (rl , q) ) 

) 

) , 
q 

) , 
r 2 , 

q 

) 

) ; 

xeq (mov_d_m(r ,ml) , m,q) = 

prog (nextmemaddr (m) , storem ( fe tchd (r , q) ,ml,q) ) ; 
xeq (mov_d_pcr ( r , i) ,m,q)= 
prog C 

nextmemaddr (m) , 
storem ( 

fetchd (r ,q) , 
offset ( i ,m) , 

q 



) ; 

xeq (mov_d_r ( rl , r2 ) ,m,q)= 

prog (nextmemaddr (m) , storer ( fetchd (rl ,q) ,r2,q) ) 
xeq (mov_d_ri ( rl , r] ) ,m ,q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchd (rl ,q) , 

atomofmemaddr ( fetchr ( r2 , q) ) , 

q 

) 

) ; 

xeq (mov_d_rid ( rl , r2 , n) ,m,q) = 
prog ( 

nextmemaddr (m) , 
stroem ( 

fetchd ( rl , q) , 
of f se t ( 
n, 

atomofmemaddr (fetchr (r2 ,q) ) 

) , 

q 

) 

) ; 

xeq (mov_d__ridn (rl,r2,il,i2) ,m, q) = 
prog ( 

nextmemaddr (m) , 
storem ( 

fetchd (rl ,q) , 
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offset ( 
i2 , 

indir ( 
il, 

atomofmemaddr ( f etchr (r2 ,q) ) 

) 

) , 
q 

) 

) ; 

xeq (mov_d_d ( rl , r2) ,m,q)= 

prog (nextmemaddr (m) , stored ( f etchd (rl , q) , r 2 , q) ) 
xeq (push_i (v, s) ,m,q) = 

prog (nextmemaddr (m) ,pushstk (v, s ,q) ) ; 
xeq (push_pcr ( i , s) ,m,q)= 
prog ( 

nextmemaddr (m) , 
pushstk ( 

f etchm (of f set ( i ,m) ,q) , 

s , 

q 

) 

) ; 

xeq (push_r (r , s) ,m,q)= 

prog (nextmemaddr (m) , pushstk ( f etchr ( r , q) s ,q) ) ; 
xeq (push_ri (r , s) ,m,q)= 
prog ( 

nextmemaddr (m) , 
pushstk ( 

f etchm ( atomofmemaddr (f etchr (r,q) ) ,q) , 
s, 

q 

) 

) ; 

xeq (push_rid (r , n ,s ) ,m,q)= 
prog ( 

nextmemaddr (m ) , 
pushstk ( 
f etchm ( 

offset ( 
n, 

atomofmemaddr ( f etchr ( r ,q) ) 

) , 
q 

) , 

S, 

q 

) 

) ; 

xeq ( push_r idn ( r , i 1 , i 2 , s ) ,m,q) = 
prog ( 

nextmemaddr (m) , 
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pushstk ( 
fetchm ( 

offset ( 
i2 , 

indir ( 

il, 

atomofmemaddr ( f etchr (r ,q) ) 

) 

) , 
q 

) , 

S , 

q 

) 

) ; 

xeq ( push_d ( r , s ) , m , q ) = 

prog (nextmemaddr (m) , pushstk (fetchd (r ,q) , s ,q) ) ; 
xeq (pop_x ( s ) / m,q)= 

prog (nextmemaddr (m) , popstk ( s ,q) ) ; 
xeq ( pop_m ( s , ml ) , m , q ) = 
prog ( 

nextmemaddr (m) , 
popstk ( 

s , 

storem ( 

topstk ( s ,q) , 
ml , 

q 

) 

) 

) ; 

xeq (pop_pcr ( s , i) ,m,q)= 
prog ( 

nextmemaddr (m) , 
popstk ( 
s , 

storem ( 

topstk (p ,q) , 
offset ( i ,m) , 

q 

) 

) 

) ; 

xeq (pop_r ( s , r) ,m,q)= 
prog ( 

nextmemaddr (m) , 
popstk ( 
s , 

s torer ( 

topstk (s ,q) , 
r , 

q 
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) 

) 

) ; 

xeq (pop_ri (s , r) ,m,q) = 
prog ( 

nextmemaddr (m) , 
popstk ( 
s , 

storem ( 

topstk (s , q) , 

atomof memaddr ( f e tchr ( r , q ) ) , 

q 

) 

) 

) ; 

xeq ( pop_rid ( s , r , n) ,m,q)= 
prog ( 

nextmemaddr (m) , 
popstk ( 
s , 

storem ( 

topstk ( s ,q) , 
offset ( 
n, 

atomofmemaddr (fetchr (r ,q) ) 

) , 
q 

) 

) 

) ; 

xeq (pop_ridn ( s , r , il , i2) ,m,q)= 
prog ( 

nextmemaddr (m) , 
popstk ( 
s, 

storem ( 

topstk ( s , q) , 
of f set ( 
i2, 

indir ( 
il , 

atomofmemaddr ( fetchr ( r , q ) ) 

) 

) , 
q 

) 

) 

) ; 

xeq (pop_d (s , r) ,m,q)= 
prog ( 

nextmemaddr (m) , 
popstk ( 
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) 



S , 

stored ( 

topstk ( s ,q) , 
r , 



) 



q 



) ; 

xeq(nop,m,q) = prog (nextmemaddr (m) ,q) ; 
xeq (stop, m,q) = prog(m,q) = q; 
xeq ( jmp (ml) ,m,q) = prog(ml,q); 

xeq ( j mp i (ml) ,m,q) = prog (atomofmemaddr ( f etchm (ml , q) ) , q) 

xeq ( jmp_r (r) ,m,q) = prog (atomofmemaddr (fetchr (r ,q) ) ,q) ; 
xeq (bra (n) ,m,q) = prog (of f set (n , nextmemaddr (m) ), q) ; 

xeq (bra_r , r ,m,q) = prog (offset (atomofint (fetchr (r,q) ) , 

nextmemaddr (m) ) ,q) ; 
xeq ( if (o , rl , r2 ,ml) ,m,q)= 
prog ( 

cond ( 

applyrop ( 
o, 

fetchr (rl ,q) , 
fetchr (r2 ,q) , 

) , 
ml , 

nextmemaddr (m) 

) , 

q 

) ; 

xeq(ifi (o,r,v,ml) ,m,q)= 
prog ( 
cond ( 

applyrop ( 
o, 

fetchr (r ,q) , 
v 

) , 
ml , 

nextmemaddr (m) 



q 

) ; 

xeq ( (if te (o , rl , r2 ,ml ,m2) ,m,q) = 
prog ( 

cond ( 

applyrop ( 
o, 

fetchr (rl ,q) , 
fetchr ( r2 ,q) 



) , 
ml , 
m2 
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) , 
q 

) ; 

xeq (iftei (o , r , v,ml ,m2) ,m / q)= 
prog ( 

cond (. 

applyrop ( 
o, 

f etchr (r , q) , 

v 

) , 
ml , 
m2 

) , 
q 

) ; 

xeq (if_pcr) o , rl , r2 ,n) ,m,q) = 
prog ( 

cond ( 

applyrop (. 
o , 

f etchr (rl ,q) 
f etchr (r 2 ,q) 

) , 

offset (n , nextmemaddr (m) ) , 
nextmemaddr (m) 



q 

) ; 

xeq ( if i_pcr (o , r , v,n) ,m,q)= 
prog ( 

cond ( 

applyrop ( 
o, 

fetchr (r , q) , 
v 

) , 

of f set (n , nextmemaddr (m) ) , 
nrxtmemaddr (m) 

) , 

q 

) ; 

xeq ( if te_pcr (o,rl,r2,il,i2) ,m,q)= 
prog ( 

cond ( 

applyrop ( 

o, 

fetchr (rl , q) , 
fetchr (r2 ,q) 

) , 

of f set ( il , nextmemaddr (m) ) , 
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offset ( i 2 ,nextmemaddr (m) ) 

) , 
q 

) ; 

xeq ( iftei_pcr (o,r ; v,il,i2) ,m,q)= 
prog ( 

cond ( 

applyrop ( 
o, 

fetchr Cr ,q) , 
v 

) , 

offset (il , nextmeraaddr (m) ) , 
of f set ( i2 , nextmemaddr (m) ) 

) , 
q 

) ; 

xeq ( test (o , rl ,ml ) ,m,q)= 
prog ( 
cond ( 

applybop ( o , fetchr ( rl , q) ) , 
ml , 

nextmemaddr (m) 

) , 
q 

) ; 

xeq ( testm (o ,m2 ,ml ) ,m,q) = 
prog ( 

cond ( 

applybop (o , fetchm (m2 , q ) ) , 
ml , 

nextmemaddr (m) 

) , 
q 

) ; 

xeq ( teste (o , rl ,ml , m2 ) ,m,q)= 

prog (cond (applybop (o , fetch (rl ,q) ) ,ml,m2) ,q) ; 
xeq ( testme (o ,m3 ,ml ,m2) ,m,q)= 

prog (cond ( applybop (o , fetchm (m3 , q) ) ,ml,m2) ,q) ; 
xeq ( test_pcr (o , rl , n) ,m,q)= 
prog ( 

cond ( 

applybop (o , fetchr (rl ,q ) ) , 
of f set (n , nextmemaddr (m) ) , 
nextmemaddr (m) ; 

) , 

q 

) ; 

xeq (tesm_pcr (o ,m2 ,n) ,m,q)= 
prog ( 
cond ( 
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applybop (o , f etchm (m2 ,q ) ) , 
of f set (n , nextmemaddr (m). ) , 
nextmemaddr (m) 

) , 

q 

) ; 

xeq ( teste_pcr (o,rl,il,i2)m,q)= 
prog ( 

cond ( 

applybop (o , fetchr (.rl ,q) ) , 
of f set (il , nextmemaddr (m) ) , 
offset(i2, nextmemaddr (m) ) 

) , 

q 

) ; 

xeq ( testme_pcr (o ,m2 , il , i2) ,m,q)= 
prog ( 
cond ( 

applybop(o,fetchm(m3,q) ) , 
off set (il ,nextmemaddr (m) ) , 
offset ( i2 , nextmemaddr (m) ) 

) , 

q 

) ; 

xeq ( j sr (ml , s) ,m,q)= 

prog (ml , pushstk ( valofmemaddr (nextmemaddr (m) ) ,s,q)) ; 
xeq ( j sr__i (ml , s) ,m,q) = 
prog ( 

atomofmemaddr (f etchm (ml ,q) ) , 

pushstk (valofmemaddr (nextmemaddr (m) ) , s ,q) 

) ; 

xeq ( j s r_r ( r , s ) , m , q ) = 
prog ( 

atomofmemaddr ( fetchr ( r ,q) ) , 

pushstk (valofmemaddr (nextmemaddr (m) ) , s ,q) 

) ; 

xeq(bsr(n,s) ,m,q) = 
prog ( 

of f set ( n , nextmemaddr (m) ) , 

pushstk (valofmemaddr ( nextmemaddr (m) ) ,s,q) 

) ; 

xeq (bsr_r (r , s) ,m,q)= 
prog ( 

offset ( 

atomof int ( fetchr (r ,q) ) , 
nextmemaddr (m) 

) , 

pushstk (valofmemaddr (nextmemaddr (m) ) ,s,q) 

) ; 

xeq(rts s,m,q)= 

prog (atmoofmemaddr ( topstk ( s ,q) ) , popstk ( s , q) ) ; 
xeq(open(s) ,m,q)= 
prog ( 
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nextmemaddr (m) , 
openf ile (. 

atomof str , char (topstk ( s , popstk ( s ,popstk 
( s , popstk ( s ,q) ) ) ) ) , 

atomof file ( topstk ( s , popstk ( s , popstk ( s , q) ) ) ) , 

atomof int ( topstk ( s , popstk ( s , q) ) ) , 

atomof int (topstk (s ,q) ) , 
popstk ( s ,q) 

) 

) ; 

xeq(close (s) ,m,q)= 
prog ( 

nextmemaddr (m) , 
closef ile ( 

atomof file (topstk ( s ,q) ) , 
popstk (s ,q) 

) 

) ; 

xeq(read(s) ,m,q)= 
prog ( 

nextmemaddr (m) , 
storem ( 

infile ( 

atomof file ( topstk ( s , popstk ( s , q ) ) ) , 

popstk ( s , q) 

) , 

atomofmemaddr (topstk (s ,q) ) , 
popstk (s ,q) 

) 

) ; 

xeq(write(s) ,m,q)= 
prog ( 

nextmemaddr (m) , 
outf ile ( 
f etchm ( 

atomofmemaddr ( topstk ( s , popstk ( s ,q) ) ) , 

popstk ( s ,q) 

) , 

atomof file ( topstk ( s ,q) ) , 
popstk ( s , q) 



) ; 

xeq (write_i ( v ,qu) ,m,q) = /* database part */ 

prog (nextmemaddr (m) , write (v,qu,q) ) ; 
xeq (write_m (ml ,qu) ,m,q)= 

prog (nextmemaddr (m) , write ( f etchm (ml ,q) ,qu ,q) ) ; 
xeq ( wr i te_r (r,qu) , m , q ) = 

prog (nextmemaddr (m) , write ( fetchr (r ,q) ,qu,q) ) ; 
xeq (dele te_x (qu) ,m,q)= 

prog (nextmemaddr (m) , delete (qu ,q ) ) ; 
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xeq (delete_m(qu,ml) ,m,q)= 
prog ( 

nextmemaddr (m) , 
delete ( 

qu, 

storem ( 

read (qu,q) , 
ml , 

q 

) 

) ; ) 

xeq (delete_r (qu , r ) ,m,q)= 
prog ( 

nextmemaddr (m) , 
delete ( 

qu, 

storer ( 

read (qu , q) , 
r , 

q 

) 

) 

) ; 

xeq(open(s) ,m,q)= 
prog ( 

nextmemaddr (m) , 
open ( 

atomof str . char (vl ) , 
atomofdb (v2) 

) 

) ; 

xeq(close(s) ,m,q)= 
prog ( 

nextmemaddr (m) , 
close ( 

atomofstr .char (vl) , 
atomofdb (v2) 

) 

) ; /* database part */ 

end extend; 
end am; 
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APPENDIX C 



A SIMPLE ASSEMBLER FOR AM 



1. Introduction 

This document is adapted from Yurchak [Ref. 2] . Appendix 
C, and constitutes the reference manual for both version 2.0- 
Z100, developed by Hunter [Ref. 3], and the latest modification 
towards version 3.0, It provides a comprehensive description 
of the syntax and semantics of the assembler as well as a 
description of the salient features of the AM machine and a 
definition of the opcodes executed by AM. 

AMASM is an assembler which generates a relocatable load 
module for the abstract machine interpreter AM. It is to the 
extent possible written in portable C. The parser and scanner 
were produced using the Unix YACC and LEX utilities. The 
output from these utilities require several patches to allow 
compilation on the Z100 using Lattice ’ C . ' Readers desiring 
to port the code to other machines may have to make slight 
changes to "defines." In this implementation, longs are 
assumed to occupy 32 bits, both int and short - 16 bits, and 
char - 8 unsigned bits. NOte : if the int size changes, then 

the infile and outfile functions in amstate.c must be changed. 

The input syntax of AMASM is similar to that of other 
assemblers. It supports symbolic addresses and constants and 
a typical set of directives, but has no macro capabilities. 

The assembler accepts an ASCII source file created on a con- 
ventional text editor and produces an output file containing 
relocation information and AM opcodes. Invoking AM causes the 
output file "a. am" to be loaded and executed. 



2. Differences from Version 1.0 

Since it was our intention to primarily specify and des- 
cribe the abstraction of a database resource, the assembler 
part, for AM was considered to be of less importance for this 
thesis. Due to the limited time the adaption of AMASM to the 
database requirements is still incomplete, only some examples 
are given which indicate a way of how to integrate this latest 
resource. Thus, for instance, although the read/write com- 
mands for the queue were developed, the method of actually 
retrieving objects from the queue has not yet been defined. 

The same is true for the database itself, where the only 
commands described are those for opening and closing the 
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database, while the other operations were left undefined for 
the above reasons. So, in fact, AM (version 3.0) represents 
only a partial extension of AM (version 2.0-Z100). 



3. Usage 

AMASM is invoked with the following command line syntax: 

amasm [ — t ] [-x] £ — s ] [-1] file . . . 

AMASM produces a single load module "a. am," which forms the 
input to the AM loader. The optional "-t" switch sends a de- 
bugging trace to "stdout," the "-x" switch provides an extended 
version of the trace, and the "-s" switch provides trace of 
the recognized scanner tokens. The optional "-1" switch gener- 
ates the listing and cross-reference file "a.x," Appended to 
this file is a hex dump of "a. am." 



4. Lexical Conventions 

Assembler tokens include identifiers (alternatively, 

"symbols" or "names"), literal constants, operators and delimiters. 

4.1. Identifiers 

Legal identifiers are described by the following regular 
expression: 

[A-Za-z] [ A-Za-zO-9 ] * 

Identifiers consist of a letter or underline followed by a 

string of zero or more letters, decimal digits and underlines. 
Upper and lower case are distinct. Identifiers may represent 
symbolic constants, instruction mnemonics, labels, addresses 
and type names. 

4 . 2. Operators 

The following are considered to be operators: 

== ;=<<=> >= 

+ -*/%& | 

The meaning of the above symbols varies with context. 

4.3. Literal Constants 

Decimal and hexadecimal constants are described by the 
following regular expressions respectively: 

[-+] [0-9] + | [0-9] + 

$ [0-9A-Fa-f]+ 
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Decimal constants consist of an optional sign followed immedi- 
ately by one or more decimal digits. Hexadecimal constants 
consist of the character "$" followed immediately by a string 
of one or more decimal digits and upper or lower case letters 
"A" through "F. " Numeric constants may represent addresses, 
integer and natural numbers, boolean and character values. 

tl It 

Character constants consist of a single quote ' , followed 

either by an ASCII character, that is not a carriage return/ 
linefeed or a numeric constant, followed by a closing single 
quote . 

String constants consist of a string of zero or more ASCII 
characters (except carriage return/linefeed) enclosed in double 
quotes . 

4.4. Blanks 

Blanks and tabs are ignored by the assembler except where 
required to separate adjacent constants or identifiers. 

4 . 5. Comments 

The character produces a comment. The assembler ignores 

all further characters on the line up to the terminating 
carriage return/linefeed. 

4.6. Delimiters 

All other characters found in the input stream are treated 
as delimiters. 



5. Statements 

A source program is composed of a sequence of statements, 
one statement per line. There are 3 kinds of statements: 
directives, instructions and null. 

Instructions and null statements may be preceded by a label. 
Directives may (in some cases, must) he preceded by an 
identifier. 

5.1. Labels & Identifiers 

A label consists of an identifier followed by a colon 
When the assembler encounters a label, the effect is to assign 
the current value of the location counter to the name. 

An identifier preceding a directive is assigned a value 
whose type depends upon the directive. For instance, the equate 
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directive assigns a typed value to an identifier, while the 
define storage directive assigns the current value of the 
location counter. 

Neither labels nor identifiers may be redefined within 
a single source file. 

5.2. Null Statements 

A null statement is an empty statement. Although ignored 
the assembler, null statements may be preceded by a label. 

5.3. Directive Statements 

A directive is a command to the assembler to perform some 
sort of operation which does not involve emitting an executable 
instruction. Typical directives (also known as "pseudo ops" 
or "pseudo instructions") allocate storage for variables, make 
names within the current module visible to other modules and 
set the location counter. Directives also produce instructions 
for the AM linker and loader. 

Directives consist of a keyword followed by zero or more 
arguments, depending upon the context. Directives and their 
syntax are described in more detail in Section 12. 

5.4. Instruction Statements 

Instruction statements produce the code which is ultimately 
executed by AM. An instruction may be preceded by a label, 
and consists of a keyword followed by zero or more arguments, 
depending upon context. 

The AM instruction set and its syntax wj 11 be described in 
detail in Section 14. 



6. The Machine 

Because AM differs from conventional machines in a number 
of important ways, some discussion is necessary before intro- 
ducing the instruction set. Outwardly similar to a number of 
well-known examples, AM instructions form an unconventional 
set of primitive operations which implement a formally speci- 
fied semantics. The reasons for this are described below. 

AM uses a tagged architecture. Thus, each data element 
contains, within it, information which uniquely identifies a 
finite set of legal operations which may be performed upon it, 
as well as a range of legal values it may take on. This set 
of operations and values is known formally as a data type-. 

AM supports a number of data types. An element of a particular 
data type will be referred to throughout the rest of this manual 
as an atom. 
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AM physical resources are partitioned into segments. There 
are several types of segments, and these together form a con- 
ventional overall model of the familiar stored program computer. 
There are memory segments (primary storage) , register seg- 
ments (high-speed memory) , display register segments (bit- 
mapped display memory), stacks, a queue, a monitor (display 
terminal attributes) and file segments (secondary storage) . 
Segments are further partitioned into discrete, addressable 
elements (alternatively, "cells") which will contain atoms 
during the execution of a program. These elements will be 
referred to repeatedly as typed values. The reason for the 
distinction between atoms and values will become more clear 
shortly. 

AM is the finite implementation of a formal specification. 

As such, data elements and the operations which can be applied 
to them must reflect a mathematical consistency not required 
by conventional architectures. Since all operations which 
affect the state of the machine must be able to "communicate" 
with each other during the execution of a AM program, they must 
do so using a common object. This object is a value. The 
memory, registers, display registers, stack, queue, and files 
all hold values. Store, fetch, execute, read, write--any 
operations which change the state of the machine--all operate 
on values ( i . e ., storage cells). All other operations, such as 
"adci," "multiply',' "and," and "or," work on atoms. Atomic 
operations in AM correspond to those which take place in the 
temporary registers of the arithmetic and logic unit of a con- 
ventional processor. 

6.1 Configuration 

A unique feature of AM is the ease with which it is possible 
to reconfigure the machine by partitioning the physical resources 
in different ways. A typical configuration would be something 
like this: 

2 memory segments 

1 register segment (with a useful number of registers) 

1 display register segment (with one or two registers) 

1 stack 

1 queue 

1 monitor (only one is permitted) 

1 database (one or more are possible) 

16 files 

The configuration chosen should provide a good indication of 
the types of programs AM is intended to execute. 

Note that, in conventional machines, stacks are implemented- 
in primary storage. This constitutes an overloading of data 
structures which obscures the intent of the user of these 
structures. It also creates a semantic nightmare for the 
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specification writer. In AM, stacks and queue take their 
rightful places as separate entities with easy to understand 
properties . 

In addition to the resources listed above, AM has a con- 
ventional program counter. 

6.1.1. Memory 

AM memory is partitioned into segments which may be of un- 
equal but fixed length. A program and its data will reside 
in memory segments. It is not necessary that code and data 
share the same segment, nor is it required that code and data 
be contiguous. The loader will determine from the origin 
directive where to load code and data values. 

The AM heap is implemented as a set of operations which 
allocate and deallocate memory segments. 

AM has a rich set of addressing modes which interact with 
a powerful move instruction which allows the programmer to 
move a value from "anywhere to anywhere." 

61.2. Registers 

AM registers form the high-speed storage into which oper- 
ands are placed. 

All atomic operations, such as add, divide and poffst, 
require operands to be in registers. Form operations are an 
exception. Their operands may be in either a register or a 
display register. 

6.1.3. Display Registers 

The form is the atomic data type that represents an image. 
Like any other atomic data type,. it may be placed in any memory, 
register, stack or file cell. A form can not be "viewed" by 
the monitor unless it is in a display register. 

Display registers may only contain form values. Each dis- 
play register has its own window which is fixed in size but 
with a variable origin. The display window determines what part 
of the form is "viewed" by the monitor. 

In general, display registers may be partitioned into mul ti- 
ple segments. However, the hardware on most machines will only 
support one segment of one or two registers. A segment of 
two display registers is equivalent to the idea of a "front" 
and "back" plane. 
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6,1.4. 



Monitor 



The monitor represents a set of terminal attributes which 
are part of the "state of the machine." The attributes: 
vertical and horizontal number of pixels, vertical and hori- 
zontal screen dimensions, intensity capability and color planes 
are fixed for any terminal. The background color and display 
register selection attributes are programmable. 

6.1.5. Stack 

The AM stack is conventional in every respect except that 
it is impossible to access any value except the top. Thus, 
frames are implemented on the heap, not the stack. 

AM has a typical set of push and pop instructions for 
operating on stacks. 

6.1.6. Files 

Input/output is implemented rather arbitrarily along the 
lines of system calls to an operating system and should not be 
considered part of AM itself. 

Instructions are provided to open, close, read to and write 
from a file. 

6 . 1. 7 . Queue 

Primarily, the queue acts as a buffer for 'objects' being 
retrieved from the database during a select operation. It is 
implemented in the same way as the stack to prevent the access- 
ing of any value except the one residing in the front position. 
This method ensures that the order of the values defining an 
object will be kept. 

A set of write and read instructions is provided for 
operating on the queue. 

6.1.8. Database 

The database consists of two major parts: the data repre- 

senting the information and a set of commands to perform the 
defined operations on it. These commands can only be applied 
to data that have explicitly been specified as a database and 
meet its structural requirements. In principle, the data need 
to be arranged as ordered pairs of lists. For database opera- 
tions all resources of AM may be used, with exception of the 
display registers and the monitor. 

Instructions are provided to open and close the database. 
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7 . 0 Atoms 



An atom is a component of a data type. The assembler 
recognizes the following type of atoms: 

file address 

pidlist 

pidsetlist 

vallist 

valsetlist 

proplist 

propsetlist 

pvallist 

pvalsetlist 

ob j 1 i s t 

classlist 

dblist 

qaddress 

As operands to instruction mnemonics, these atoms form the 
familiar set of literal and symbolic constants found in typi- 
cal assembly language programs. 

With certain exceptions, atoms may appear in the form of 
literal constants: 

100 
$d0f 1 

' a ' 

"this is a string atom" 

They may also appear as symbols which take on the value of the 
atom in some other part of the source program. With few excep- 
tions, anywhere a literal constant may be used, a symbolic 
constant of the appropriate type may also be used. 

The assembler distinguishes between types of atoms using 
syntax and context. The syntax is described below. 

7.1. Boolean 

A boolean atom has only two values, true and false. These 
values are represented to the assembler by the decimal or 
hexadecimal constants for 1 and 0, respectively. 

0 

1 

$1 

$0 

are legal boolean atoms. 

7.2. Natural 

This type represents as the name implies, the natural (un- . 
signed) numbers. Legal values range from zero to positive 
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infinity. Natural numbers are represented to the assembler as 
decimal or hexadecimal constants whose values are greater than 
or equal to zero. 

0 

$2 f 5 
240 

are legal natural atoms. 

7.3. Integer 

Integers range from negative to positive infinity, and are 
specified as hexadecimal or signed or unsigned decimal constants. 

-250 

0 

$ed67f 

+10 

are legal integer atoms. 

7.4. Character 

Character atoms may take values defined by the ASCII 
character set. They are represented to the assembler as literal 
character constants. 




are legal character atoms. 

7.5. String 

String atoms are composed of zero or more concatenated ACIII 
characters. They are specified as literal strings. 

"this is a legal string atom" 

II It 

are both legal string atoms. 

7.6. Intensity 

An intensity atom ranges from 0 to 199 decimal. It is 
represented as a unsigned decimal or hexadecimal constant pre- 
ceded with the character "0" represents the null intensity 

which is used to construct the null color. 

&0 
&0 
&89 
&19 9 

are legal intensity atoms. 
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7.7. Color 



A color atom is a composite of a red, green and blue inten- 
sity. It is represented as an ordered triple of unsigned 
decimal or hexadecimal constants separated by commas 
enclosed within parenthese and preceded with The 

nullcolor provides the concept of background and transparency. 
It is represented as the "@" enclosed within parentheses and 
preceded with 

&( 0 , 0 , 0 ) 

& (70 , 0 , 190) 

&@ 

are legal color atoms. 

7.8. Point 

Points are composed of integer pairs. The x and y coor- 
dinates correspond to the first and second integers respec- 
tively. Increasing integer values represents positions 
shifted right and up. A point is represented as an ordered 
pair of decimal or hexadecimal constants separated by a 
comma ","and enclosed within parentheses 

( 0 , 0 ) 

(4,1047) 

(-8,25) 

(-50677,-293399) 
are legal point atoms. 

7.9. Rectangles 

Rectangles are composed of a pair of points which repre- 
sent the opposing corners. A rectangle is represented as an 
unordered pair of points separated by a colon and enclosed 

within square brackets 

[ ( 0 , 0 ) : ( 0 , 0 ) ] 

[ (0,0) : (50,45) ] 

[ (50,45) : (0,0) ] 

[ (-20,-20000) : (30,59) ] 

are legal rectangle atoms, 

7.10. Form 

A form atom is a composite structure. It has a two dimen- 
sional size and a color map which is an array of colors with 
each color corresponding to a point in its area. The form 
atom has no literal constant representation. It is created 
using the operator, newfrm, and modified using other operators. 
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7.11. Font 



A font atom is an array of forms. The font atom has no 
literal constant representation. It is constructed from the 
operator, newfnt, and modified using other operators. 

7.12. Ptblt 

A ptblt atom is a composite of three rectangles and a 
natural which represents a copy rule. The ptblt atom has no 
literal constant representation. It is constructed from the 
operator, newblt, and is modified using other operators. 

7.13. Memory Address 

Memory address atoms consist of two components: a segment 

address, and an element address. Memory addresses are repre- 
sented as an ordered pair of unsigned decimal or hexadecimal 
constants, separated by a colon and enclosed within 

parentheses 

( 0 : 100 ) 

represents memory segment 0, element 100. 

( 2 :$ 10 ) 

represents segment 2, element 16. 

Segment and element addresses start at 0. The number and 
size of available memory segments depends upon the current 
configuration of AM. 

Labels are considered memory address atoms, as are names 
which appear to the left of the define storage and define 
constant directives. 

7.14. Register Address 

Register address atoms have a syntax identical to that of 
memory addresses except that a lower case "r" is prepended to 
the address. 

r (0 :3) 

refers to register segment 0, register 3. 

Segment and element addresses start, as with memory addresses, 
at 0. The number of register segments, and the number of 
registers within each segment, varies as determined by the 
current AM configuration. 

7.15. Display Register Address 

Display register address atoms have a syntax identical to 
that of register addresses except that the lower case "r" is 
replaced with a lower case "d" . 
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d (0 : 1) 

refers to display register segment 0, register 1. 

Segment and element addresses start at 0. The number of 
display register segments, and the number of display registers 
within each segment, varies as determined by the current AM 
configuration . 

7.16. Monitor Attribute 

The monitor consists of eight attributes values which are; 

x — represents number of horizontal pixels (natural) 
y--represents number of vertical pixels (natural) 
v — represents screen height in inches (natural) 
h — represents screen width in inches (natural) 
i — represents intensity capability (natural) 
c — represents number of color planes (natural) 
b — current background color (color) 
d--selected display register to view 
(display register address) 

A monitor attribute is represented by a dash followed by 

one of the above characters for the indicated attribute. 



-x 

-y 

-b 

are all legal monitor attribute atoms. 

7.17. Stack Address 

A stack address has only one component: the segment address. 
Stack addresses are specified by prepending a lower case "s" 
to an unsigned decimal or hexadecimal constant enclosed within 
parentheses . 

s ( 2 ) 

refers to stack segment 2. 

Stack addresses begin at 0. The number of stacks depends 
upon AM’s configuration. 

7.18. File Addresses 

File address atoms may not appear in a program except within 
typed values. File address atoms are represented as unsigned 
integer or hexadecimal constants. 

‘File addresses start at 0. The number of files which may 
be open at one time is determined by the current AM configura- 
tion. The first three file addresses (0,1,2) are normally 
opened automatically by AM when a program is loaded. 
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7.19. 



Pidli st 



Pidlist atoms are composed of one or more concatenated 
ASCII characters and form single strings that must not be 
empty. They are surrounded by angle brackets. 

<name> 

<id> 

<grade_l> 

are all legal pidlist atoms. 

7.20. Pidsetlist 

This type represents a number of zero or more pidlists, 
separated by commas and enclosed within a set of angle 

brackets . 

<name , age , grade> 

< > 

are both legal pidsetlist atoms. 

7.21. Vall.ist 

Vallists are represented like pidlists as strings of one 
or more concatenated ASCII characters. Type distinction is 
made in accordance with the context in which they appear. 
Arithmetic operations on vallist atoms are not possible since 
they are treated as characters. 

<123> 

<A> 

are legal vallist atoms. 

7.22. Valsetlist 

Analogous to the pidsetlist, valsetlist atoms are composed 
of zero or more vallists, separated by commas and enclosed 

within a set of angle brackets. Since a valsetlist atom is 
actually used to define a certain domain of values, it most 
likely will be of the following form: 

<1,2 , 3,4 , 17, 1 2 3 > 

< A , B , C , D , E , F> 

<Monterey , San_Diego> 

< > 



but 

< John , Cindy , Monterey > 
would also be a legal vaJsetlist atom. 
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7.23. Proplist 



Proplists are composed of ordered pairs that consist of a 
pidlist and a valsetlist, additionally enclosed within angle 
brackets and separated by a comma " , " . 

< <name> ,< John , Cindy , Mark > > 

< <grade> , <A, A- ,B+> > 

are legal proplist atoms. 

7.24. Propsetlist 

Propsetlist atoms are represented by zero or more prop- 
lists, additionally enclosed within angle brackets and separated 
by commas Since a proplist consists of the ordered pair 

pidlist and valsetlist, a propsetlist atom also contains a 
number of ordered pairs. 

< < <name> ,< John , Cindy ,Mary> >, 

< <age> , <20 , 10 , 30 , 17 , 65> > > 

is a legal propsetlist atom. 

7.25. Pvallist 

This type is composed of the ordered pair pidlist and 
vallist separated by a comma and additionally enclosed 

within angle brackets. 

< <name> , < John> > 

< <name> , <Cindy> > 

< <age>,<17> > 

are legal pvallist atoms. 

7.26. Pvalsetlist 

A pvalsetlist atom consists of zero or more pvallists,- 
separated by commas " , " and additionally enclosed within angle 
brackets. It is arranged as a number of ordered pairs. 

< < <name> , < John> >,< <age>,<25> >, < <city> <Monterey> > > 
<<>> 

are both legal pvalsetlist atoms. 

7.27. Objlist 

Objlists are composed of zero or more different pvallists 
and can be considered as particular pvalsetlists . An objlist 
consists of a number of ordered pairs that like a pvalsetlist, 
are enclosed within an additional set of angle brackets and 
separated by commas It can be empty, although this would 

not be meaningful. 
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< < <name> , < John> > > 

< < <name> , <Cindy> >,< <sex> , < female> >,< <age>,<20> > > 

<<>> 

are legal objlist atoms. 

7.28. Classlist 



This type is represented by zero or more obj lists, addi- 
tionally enclosed within angle brackets and separated by commas 
It is mandatory that all obj lists belonging to the same 
classlist are equally structured. That is, their pidlist 
atoms must be identical. 



< < < <name>,<John > >,< <age>,<25> > >, 

< < <name> , <Cindy> >,< <age>,<19> > >, 

< < <name>,<Paul > >,< <age>,<20> > > > 



is a legal classlist atom. 



7-29. Dblist 



The dblist is composed of zero or more classlists which 
are additionally enclosed within angle brackets and separated 
by commas An objlist atom can only be contained in the 

dblist if it is part of a classlist that itself must be contained 
in the dblist. Since the structure is top-down, a pidlist not 
included in any classlist may be comprised in the dblist, but 
never the reverse. 

The following shows a legal dblist atom: 



< 


< 


< 


<name> , < John > 


>,< <score> , <375> 


> 


> , 






< 


< 


<name> , <Mary> 


>,< <score> , <380> 


> 


> > 


f 


< 


< 


< 


<course> , <CS4600> >,< <room>,<13> 


> , < 


<hours> , <4 . 0> > 




< 


< 


<course> , <OR3333> >,< <room>,<42> 


> , < 


<hours> , <4 , 5> > 


< 


< 


< 


<ID>,<ab> >,< 


<est>,<rl9> > >, 










< 


< 


<ID>,<xy> >,< 


<est> , <o23 > > > , 










< 


< 


< ID> , <vw> > , < 


<est>,<a95> > > > 


> 







The database structure is simple and can easily be disclosed. 

The first list of this structure always corresponds to the 
first object class, while the first list of an object class is 
equivalent to its first object. Then the first list of an 
object represents its first property value which itself contains 
the propertv_id as first element and the corresponding value as 
its second. 



7.30. Qaddress 

The only component of a queue address is the segment address. 
Queue addresses are specified by prepending a lower case "q" to 
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an unsigned decimal or hexadecimal constant enclosed within 
parentheses . 

q ( 1 ) 

refers to queue segment 1. 



8. Typed Values 

Some of the atomic types may also appear as typed values 
in certain instructions and directives. A typed (immediate) 
value is represented as an ordered pair consisting of a key- 
word representing the type, and the atom itself, separated by 
a comma and enclosed within curly braces 

{ int . 100 } 

represents the integer value 100. 

{addr. (1:100) } 

represents memory address value (1:100). 

A list of the types which may be used as immediate values 
alongside the corresponding keywords appears below: 

bool — boolean 

nat — natural 

int — integer 

char- -character 

string--character string 

intens--intens ity 

color--color 

pnt--point 

ret- -rectangle 

addr--memory address 

file--file address 

pidlist — property id list 

pidsetlist — property_idset list 

vallist--value list 

val setlist--valueset list 

proplist--property list 

propsetlist — propertyset list 

pvallist — propertyvalue list 

pvalsetlist — propertyvalue set list 

ob j list--ob ject list 

classlist objectclass list 

db!ist--database list 

Immediate values are used, as in conventional assembly languages, 
for loading constants into cells, initializing storage, pushing 
parameters to subroutines on the stack, and so on. 

A special syntax may be applied when expressing typed values 
for the define storage and define directives. The type 
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keyword may be followed by a list of atoms of the appropriate 
type, separated by commas. 

{ int ,1,2, 3, 4, 5, 6, 7,8} 

shows an example of this. 



9. Expressions 

An expression may be substituted anywhere an integer or 
natural atom is called for. The expression must be a sequence 
of integer/natural atoms (and symbolic constants equated to 
integer/natural atoms) separated by operators and grouping 
symbols which, evaluates to an atom of the type called for 
where the expression is used. 

9.1. Expression Operators 

Legal operators are (in order of increasing precedence): 

- or 

& - and 

+- - addition and subtraction 

*/% - multiplication, division, and modulus 

- unary minus 

Expressions may be grouped using parentheses "("")". 



10. Notation 

Throughout the rest of this manual, the following notational 
conventions will be used to describe the syntax of directives 
and instructions. 

A - atom 

V - typed value 

N - natural atom 

I - integer atom 

M - memory address atom 

R - register address atom 

D - display register address atom 

C - either a display or a high speed register address atom 
T - monitor attribute atom 
S - stack address atom 

< > - items enclosed within angle brackets are arguments 
[] ' - items enclosed in square brackets are optional 
<ea> - effective address 
<ev> - effective value 
Q - queue address atom 
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11. Data Format 



AMASM emits object code and directives using AM I/O 
modules. The object module is, thus, directly readable by AM. 
A linker and loader may be written either in a high level 
language, or AM assembler. 



The data and object module formats described below are a 
direct reflection of AM's tagged architecture. The following 
conventions will apply: 

- All numbers shown are in hexadecimal. 



- The letter "H" is a place holder signifying any 4-bit value. 

- The letter "D" is a place holder signifying any 32-bit value 

- The letter "P" is a place holder signifying a 32-bit pointer 

- The general form of a typed value is 



tag 



val 



where "tag" is a 16-bit type field, and 
8 to 32-bit value or a 32-bit pointer. 



"val" 



is either an 



Note the following: 



- Character string atoms and values have a 16-bit size field 
inserted after the type field which indicates the number 
of characters in the value field (including the ter- 
minating null) . This size field is omitted in memory 
(since it is not needed) and replaced by a pointer to 
the string. 

- Instruction values have a 32-b.it pointer following the 
type field, which points to an array of values. The 
first value is the opcode followed by the operands. 

The number of operands is encoded in the opcode. 

- Form values have a 32-bit pointer to a form header. 

The header contains the form's rectangle and a pointer 
to the cmap which is an array of colors. The length 
of the cmap is determined from the form's rectangle. 

- Font values have a 32-bit pointer to a font header. 

The header contains the font' rectangle and a 128 member 
array of cmap pointers. 



- All list atoms and values with the exception of the 
dblist type have a 16-bit size field that is inserted 
after the type field and indicates the number of charac- 
ters contained in the value field. Similar to the 
string type, this size field is replaced in memory by 

a pointer to the corresponding list. 

- Dblist atoms and values have a 32-bit size field in- 
serted after the type field which indicates the number 
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of characters in the value field and represents the total 
number of characters contained in the database. In 
memory the size field is replaced by a 32-bit pointer to 
the dblist. 



A number of the formats listed below are not described else- 
where in this manual since they are either not accessible to 
the programmer, or are implied by context. 

11.1. Atom Formats 



0001 



0002 



boolean - 
natural - 
integer - | 0003 
character - 



HH 



HHHH 



HHHH 



0004 



HH 



character string - j 0005 
intensity - 



| ~p~f I hh. . . 00 



0006 



HH 



color - 
point - 



0007 




HH HH HH 


0008 


: m i 


DD | 



rectangle - 


0009 | |P| DDDD| 


form - 000A 


|Tf |DD DD 


' n ' 


font - 000B j | P J |DD DD 


| -128 



-cmap array- 



ptblt - | 000C | [¥] jDDDD DDDDDDDD HH 



memory address - j 0030 
register address - 






0031 






display 


register address - 


| 0032 


monitor 


attribute - 


0033 | 


HH 






stack address - 
file address - 



0034 | \1P 



0035 



HHHH 



0040 



monadic operator - 
dyadic operator - ] 0041 

triadic operator - 



HHHH 



HHHH 



0042 



HHHH 



0043 



0044 



0045 



quadadic operator - 
sexadic operator - 
octadic operator - 
relational operator - 
boolean comparator - 
pidlist - 000D I |TJ |HH. . . 00 



HHHH 



HHHH 



HHHH 



0046 



HHHH 



0047 



HHHH 



pidsetlis t - | 00 0E I j P | I HH. . . 00 
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11 . 



vallist - | POOF | | P 1 | HH. . . 00 



proplist - 
propsetlisl 
pvallist - 



- 0010 I |Tf HH. . . 00 


0011 


tl 

m 

o 

o 






0012 | |Tj 


HH. . . 00 


0013 


|pl | HH ... 00 






0014 | |Tf 


HH. . . 00 



objlist - 
classlist - 
dblist - 



0015 1 | Pi | HH. . . 00 

0016 | |TT 



HH. . . 00 



0017 ! |TT I D ... 00 



qaddress - 
2. Value Formats 



0036 | |jT] 



boolean - 
natural - 
integer - 



0201 



HH 



0202 



HHHH 



0203 



HHHH 



0204 



character - 
character string - 
intensity - 
color - 



HH 



0205 0 | HH 



00 



0206 



HH 



point - 



0207 


|HH HH HH 


0208 


0 ! 


DD | 



rectangle - 


0209 1 

L 


| P] DDDD | 


form - 020A 


. 0 1 


| DD DD 


| P | -cmap array- 


font - 020B 


. 0 


DD DD 


| -128P 1 s- 



ptblt - | 020C j |T] | DDDD DDDD DDDD HH 



memory address - | 0230 



0 

0231 | \~D] 



register address - 
display register address - 
monitor attribute - 
stack address - 
file address - 



0232 1 |~D] 



0233 



HH 



02 3 4 



0 



0235 



HHHH 



instruction - I 0250 
pidlist - | 020D ' | ~P~f 

pidsetlist - 
vallist - 



|Tj HHHH 


zero or more operand atoms 


] | HH. . . 00 





02011 IT] HH ...00 



020F | | T 1 | HH. . . 00 



valsetlist - | 0210 | | ~P~[ | HH. . .00 
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proplist - 0211 


| P | I HH. . . 00 


propsetlist - 


0212 | [¥] HH. . . 00 ! 


pvallist - 0213 


|"P] | HH. . . 00 | 


pvalsetlist - 


0214 | [p] HH. . . 00 | 


objlist - 0215 


. fp] | HH. . . 00 


classlist - 0216 | |p| HH...00 


dblist - 0217 


\~p] I D ... 0 0 


qaddress - 0236 | |~D"j 



11.3. Object Module Format 

The structure of an object module is very simple. The 
only object always found is a leading org directive. Next, if 
any symbols were declared global or external in the source 
module, a pseudo instruction will be emitted for each such 
symbol. The rest of the file contains executable and pseudo 
instructions emitted as they occur in the source. 



12. Assembler Directives 



AMASM recognizes the following directives: 



equ 

org 

rorg 

extern 

globl 

trace 

ds 

dc 



equate 

absolute origin 
relative origin 
external symbol 
global symbol 
trace execution 
define stroage 
define constant 



Directives do not produce code which will be executed by AM, 
but they may cause linker/loader instructions to be emitted. 
The meaning and syntax of each directive is described in the 
following pages. 
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EQU 



Equate 



EQU 



Syntax : 

<name> equ <equivalence> 
where : 

<name> is any legal identifier 
<equivalence> is any atom or typed value 

Description : 

The symbol <name> is assigned the value of <equivalence> . 
Elsewhere in the source module, the symbol may be used in place 
of a literal value of the same type as <equivalence> using the 
following syntax: 

- If the symbol represents a memory address atom, the symbol 
may be used directly. 

- If the symbol represents a typed (immediate) value, it 
must be enclosed in curly braces 

- If the symbol represents an integer or natural atom, it 
must be preceded by a pound sign 

Example : 



propseg 


equ 


(0:0) 


dataseg 


equ 


(1:100) 


offset 


equ 


10 


datafile 


equ 


file, 3 




org 


progseg 




move 


{addr , data } , r ( 0 : 0 ) 




move 


{ int ,100},r(0:0)@#offset 




push 


{ string , " test . dat " } s ( 0 ) 




push 


{datafile } , s ( 0 ) 




push 


{ int , 0 } , s ( 0 ) 




push 


{ int , 0 1 , s ( 0 ) 




open 

stop 


s ( 0 ) 




org 


dataseg 


data 


ds 


100 



"progseg" and "dataseg" are equated to memory address atoms, 
"offset" is equated to the integer atom 10. 

"datafile" is equated to the file address value (file, 3}. 
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Format : 



equ does not cause an 



emission . 
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ORG 



Absolute Origin 



ORG 



Syntax : 

org [M] 

Description : 

The location counter is reset to M, if specified; other- 
wise i't remains unchanged. All memory addresses and labels 
specified after an org directive up to the next org or rorg 
directive not explicitly expressed as displacements are 
treated as absolute addresses. Code generated after an org 
directive up to the next org or rorg directive is not 
relocatable . 



Example : 


org 






move 


( 0 : 0 ) , r ( 0 : 0 ) 




org 


(1:0) 


data 
Format : 


ds 


{int, 100} ,{nat,0} 


0250 


1801 0230 [D] 



293 



RORG 



Relative Origin 



RORG 



Syntax : 

rorg [M[ 

Description : 

The location counter is reset to M, if specified; other- 
wise it remains unchanged. All memory addresses and labels 
specified after a rorg directive up to the next org or rorg 
directive are computer as displacements. Code generated after 
a rorg directive up to the next org or rorg directive is 
relocatable (program counter independent) . 

Example : 



rorg 



move { int , 100 }, data 

jsr stuff 

stop 



data 



ds 



10 



In the above example, the move would be emitted using 
destination program counter relative addressing. 



Format : 



0250 



1801 j | 0230 | \W[ 
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EXTERN 



External Symbol 



EXTERN 



Syntax : 

extern <name>. . . 
where : 

<name> is any legal identifier 
Description : 

The list of symbols is made visible to the current module 
and is assumed to be defined elsewhere. An error is flagged 
if a symbol in the list is not referenced somewhere within 
the current module. It is also an error for any symbol in 
the list to be defined within the current module. 

Example : 



extern expon 

push { int , 100 } , s ( 0 ) 
jsr expon, s(0) 



Format : 

For each symbol decalred external, an extern pseudo op is 
emitted, followed by a string containing the symbol. 



0250 


1802 




0205 


■ m 


HH. . . 00 
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GLOBL 



Global Symbol 



GLOBL 



Syntax : 

globl <name> . . . 
where : 

<name> is any legal identifier 
Description : 

The list of symbols is made visible to external modules. 
Each name in the list must be defined as a memory address 
somewhere within the current module. 

Example : 

globl test, data 

test : 

move (0:0) , r ( 0 : 0 ) 
stop 

data ds 10 

"test" and "data" are made visible to other modules. 



Format : 



For each symbol declared global, a globl pseudo op is 
emitted, followed by a string containing the symbol, followed 
by a memory address representing the value of the symbol. 



0250 



1803 



00~05~[ 



in 



HH. . . 00 



0230 
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TRACE 



Trace Execution 



TRACE 



Syntax : 

trace <f lag> , <toggle> 

where : 

<flag> is "-t" for normal trace and "-x" is for extended 
trace 

<toggle> is "+" for on and for off 

Description : 

A trace of the programs execution is available in two 
modes, normal and extended. The normal mode traces the main 
function calls and the major paths through them. The extend 
mode includes the normal trace plus memory allocation calls and 
creation of temporary values. The trace directive may be 
selected in the command line when AM is invoked, or embedded 
in the source code to enable trace over selected portions of 
the program. 

Example : 



progseg 




equ (0:0) 




org 


progseg 




move 


{ addr ,data} , r ( 0 : 0 ) 




trace 


-t,+ 




move 


{int,100} ,r (0:0) @ 




trace 


-t , - 




push 

stop 


{ int , 0 } , s (0) 


data 


ds 


100 



Format : 



0250 




3800 




0204 




HH 




0203 




KHHH 
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DS 



Define Storage 



DS 



Syntax: 



[<name>] ds N[V...] 

[ <name> ] ds [N] V. . . 

where : 

<name> is an optional identifier 

ds permits a list of atoms to follow the type keyword of 
each value. 

Description : 

ds allocates storage for values starting at the current 
value of the location counter. 

- If N is specified and N is greater than or equal to the 
number of values in the list, space for N values is 
allocated and the location counter is incremented by N. 

- If N is specified and N is less than the number of values 
in the list, N is ignored. 

- If N is not specified, the amount of storage allocated 
is equal to the number of values in the list. The loca- 
tion counter is incremented by this number. 

- If a value list is specified, the allocated cells will 

be initialized to those values, beginning with the first. 

- Cells allocated but not initialized are considered to 
hold undefined values. It is an error to attempt to 
read an undefined value. 



The first ds allocates 10 values and leaves them undefined, 
"datal" may be used to index into those values. 

The second also allocates 10 values, but initializes the 
first to the integer 100, and the next 3 to the naturals 
0, 20, and 40. The last 6 values are left undefined. 

The third ds shown allocates 2 character values. 



Example : 



data 1 

data2 

data3 



ds 10 

ds 10 { int , 100 } , { nat , 0 , 2 0 , 4 0 } 

ds {char, 1 a 1 , 'b ' } 

ds { string ," this is a string value"} 
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The fourth allocates a single string value. No identi- 
fier was specified. 

Format : 

A typed value is emitted for each value in the list. In 
addition, ds will emit an org pseudo op (see org) whenever 
the number of values in the value list is less than N. 
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DC 



Define Constant 



DC 



Syntax : 

[ <narae>] dc V. . . 
where : 

<name> is an optional identifier 

dc permits a list of atoms to follow the type keyword of 
each value. 

Description : 

dc allocates and initializes storage from a list of values 
starting at the current value of the location counter. 

Example : 

data3 dc { char , ' a ’ , ' b ' } 

dc { string this is a string value"} 

The first ds shown allocates 2 character values. 

The second allocates a single string value. No identi- 
fier was specified. 

Format : 

A typed value is emitted for each value in the list. 
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13. Addressing Modes 

AM supports 11 addressing modes: 

d - display register direct 

r - register direct 

ri - register indirect 

rid - register indirect with displacement 

ridn - n-level register indirect with displacement 

m - memory absolute 

mi - memory indirect 

per - program counter relative 

i - immediate value 

a - immediate atom 

s - stack direct 

q - queue direct 

Like other more familiar processors, not all AM instructions 
can use all of the addressing modes. 

In addition, AMASM supports address expressions, which 
provides a rudimentary indexing capability. 

13.1. Display Register Direct 

The form operand is in the display register. 



Syntax: D 

Format : 



0232 



in 



13.2. Register Direct 

The operand is in a register. 

Syntax: R 

Format : 

0231 i in 

13.3. Register Indirect 

The address of the operand is in a register. 
Syntax: R@ 

R - holds the operand address 



Format : 
0231 



in 
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13.4. Register Indirect with Displacement 



The address of the operand is the sum of the address in a 
register and an integer displacement. 

Syntax: R@I 

R - holds a base address 

I - an integer displacement 



Format : 
0231 



in 



0203 



! HHHH 1 



13.5. N-level Register Indirect with Displacement 



The address of the operand is the sum of the address ob- 
tained from the nth link in a chain of dynamic links and an 
integer displacement. 



Syntax: RN@I 



R - holds the current frame pointer 

N - a non-negative frame reference 

I - an integer frame displacement 



(RN@I) is equivelent to R@I) 



Format : 



0231 


| D | [0202 




HHHH 




0203 





HHHH 



13.6. Memory Absolute 



Syntax: M 

M - the operand address 

Format : 

0230 j |1[[ 



13.7. Memory Indirect 

The address of the operand is in a memory cell. 
Syntax: M@ 

M - a pointer to the operand address 



Format : 

1 0230 
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13.8. Program Counter Relative 

The address of the operand is the sum of the program counter 
and an integer displacement. 

Syntax: M 

M - the operand address 

The specified address must be in the same module as the instruc- 
tion. The assembler automatically computes the displacement. 
Program counter relative is specified for a block by placing 
a rorg directive at the top of the block. 



Format : 



0203 



\m 



13.9. Immediate Value 



The operand is an immediate value. 



Syntax: V 



V - any typed value 



Format : 



tag 



valu 



13.11. Stack Direct 



The operand is a stack. 
Syntax: S 

Format : 



0234 



cm 



13.12. Queue Direct 

The operand is a queue. 
Syntax: Q 

Format : 



0236 



in 



14. Instruction Set 



The AM instruction set is simple but powerful. The rigid 
data types make it meaningless to specify operations likq shift 
and mask, thus removing some of the programmer's freedom to 
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muck with data in arbitrary ways. The tagged architecture will 
detect errors like jumping to data, or accessing instructions 
as data, as well as the more common bounds checking performed 
by runtime libraries. 

141. Machine Errors 

The following errors are detected by AM during loading and 
execution : 

- attempt to execute a non- instruction 

- attempt to execute an illegal instruction 

- memory segment not defined 

- memory segment overflow 

- memory segment underflow 

- register segment not defined 

- register segment underflow 

- register segment underflow 

- display register segment not defined 

- stack segment not defined 

- undefined monitor attribute 

- <file> contains unresolved references 

- attempt to convert negative int to nat 

- no predecessor to zeronat 

- no predecessor to minintens 

- no successor to maxintens 

- addition illegal with nullintens 

- subtraction illegal with nullintens 

- gtintens illegal with nullintens 

- ltintens illegal with nullintens 

- geintens illegal with nullintens 

- leintens illegal with nullintens 

- illegal color definition 

- form is not correct size for font 

- icon is undefined 

- unknown operator to applymop 

- unknown operator to applydop 

- unknown operator to applytop 

- unknown operator to applyqop 

- unknown operator to applysop 

- unknown operator to applyoop 

- unknown operator to applyrop 

- unknown operator to applybop 

- type error - GT 

- type error - GE 

- type error - LT 

- type error - LE 

- no more segment available 

- attempt to free invalid memory segment 

- attempt to free non-allocated segment 

- stack empty 

- stack overflow 

- stack underflow 
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file already open 

unable to close file 

unable to open <file> 

file already closed 

file not open 

file not open for reading 

file not open for writing 

reading file, type not recognized 

error reading file 

writing file, type not recognized 

invalid memory segment 

memory segment not allocated 

invalid memory address 

invalid register segment 

invalid register address 

invalid stack segment 

invalid file descriptor 

attempt to return head of null string 

value not of type bool 

atom not of type bool 

value not of type int 

atom not of type int 

value not of type nat 

atom not of type nat 

value not of type char 

atom not of type char 

value not of type string 

atom not of type string 

value not of type ilev 

atom not of type ilev 

value not of tyep coir 

atom not of type coir 

value not of type pnt 

atom not of type pnt 

value not of type ret 

atom not of type ret 

value not of type form 

atom not of type form 

value not of type font 

atom not type font 

value not of type ptblt 

atom not of type ptblt 

value not of type mad 

atom not of type mad 

value not of type rad 

atom not of type rad 

value not of type dad 

atom not of type dad 

value not of type mattribute 

atom not of type mattribute 

value not of type sad 
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- atom not of type sad 

- value not of type file 

- atom not of type file 

- value not of type mop 

- atom not of type mop 

- value not of type dop 

- atom not of type dop 

- value not of type top 

- atom not of type top 

- value not of type qop 

- atom not of type qop 

- value not of type sop 

- atom not of type sop 

- value not of type oop 

- atom not of type oop 

- value not of type rop 

- atom not of type rop 

- value not of type bop 

- atom not of type bop 

- value not of type instr 

- atom not of type instr 

- type error 

- queue segment not defined 

- queue empty 

- queue overflow 

- queue underflow 

- db already open 

- unable to close db 

- unable to open <db> 

- db already closed 

- db not open 

- illegal object insertion 

- object not contained in class 

- invalid queue segment 

- atom not of type pid 

- value not of type pid 

- atom not of type val 

- value not of type val 

- atom not of type pval 

- value not of type pval 

- atom not of type obj 

- value not of type obj 

- atom not of type db 

- value not of type db 

- atom not of type 1st 

- value not of type 1st 

All machine errors are fatal. 
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14.2. Assembler Errors 



AMASM will detect and report the following errors: 

- symbol not an address 

- symbol defined locally 

- <symbol> does not match declared type 

- relative memory indirect not permitted 

- symbol not a value 

- symbol not an integer 

- intensity value exceeds range 

- symbols declared but not referenced 

- displacement from external addresses not permitted 

- relative addressing not permitted between segments 

- out of symbol space 

- symbol declared external 

- symbol already defined 

- symbol not of same type 

- impossible value for given type 

- syntax error 

Assembler errors are not fatal, but will prevent the crea- 
tion of the object module and, usually, the cross-reference 
file. 

14.3. AM Operations 

AM supports a useful set of monadic, dyadic, triadic, 
quadadic, sexadic, octadic, relational and test operators. 
These operators are to be used with the monad, dyad, triad, 
quad,sexad, octad, if and test instructions. The mnemonics/ 
symbols for each operator along with the data types to which 
each may be applied are described below. 

14.3.1. Monadic Operators (MOP's) 

not - boolean negation 

not accepts a boolean argument and returns its negation 
abs - absolute value 

abs accepts an integer argument and returns is absolute 
value 

ntoi - natural to integer 

ntoi accepts a natural argument and converts it to an 
integer 

iton - integer to natural 

iton accepts an integer argument and converts it to a 
natural 
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len - string length 

len accepts a string argument and returns its length as 
a natural number. 

make - make a string 

This operator accepts a character argument and returns a 
string of length 1. 

head - the head of a string 

This operator accepts a string argument and returns the 
character at its head. It is an error to take the head 
of an empty string. 

tail - the rest of a string 

tail accepts a string argument and returns a string con- 
taining all but the first character. The tail of an 
empty string is the empty string. 

remp , gcmp ,bcmp - color components 

remp, gcmp and bcmp accept a color argument and return 
the respective red, green, or blue component of the 
color. 

xcord,ycord - point coordinate 

xcord and ycord accept a point argument and return the 
respective coordinate integer. 

origin , corner - rectangle corner points 

These operators accept a rectangle argument and return a 
corner point. Origin returns the lower left and corner 
the upper right. 

xdim,ydim - rectangle dimensions 

xdim and ydim accept a rectangle argument and return the 
respective dimension integer. 

newfrm - new form 

newfrm accepts a rectangle argument and returns a new blank 
form whose rectangle is the same as the input rectangle. 

farea - form area 

farea accepts a form argument and returns its rectangle. 

gbits , gbltd , gbltc - get ptblt rectangles 

These operators accept a ptblt argument and return the 
specified rectangle. gbits returns the source, gbltd 
returns the destination, and gbltc returns the clipping 
rectangle . 
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gbltr - get ptblt rule 

gbltr accepts a ptblt argument and returns the natural 
that represents the copy rule. 

newfnt - new font 

newfnt accepts a rectangle argument and returns an empty 
font whose icon rectangles are the same as the input 
rectangle . 

rctfnt - rectangle of font 

rctfnt accepts a font argument and returns its rectangle, 
lenfnt - length of font 

lenfnt accepts a font argument and returns the number of 
icons in it as a natural. 

makenew - make a list 

This operator accepts a list argument and returns a new 
list . 

first - the first list 

first accepts a list argument and returns the first list 
contained in it. It is an error to take the first of an 
empty list. 

rest - the rest of a list 

rest accepts a list argument and returns a list containing 
all but the first list. It is an error to apply this 
operator to the empty list. 

sofirst - set of first lists 

This operator accepts a list and returns the set of all 
first lists contained in it. Applying sofirst to a list 
which does not contain at least two sublists results in 
an error. 

14.3.2. Dyadic Operators (DOP's) 
and , or 

and and or accept two boolean arguments and return a boolean 
result . 

add , sub ,mul , div ,mod - computational operators 

These operators accept integer, natural or intensity argu- 
ments (both of the same type) and return a result of that 
type. Divide by zero returns an error. div discards any 
remainder. mod returns the remainder. mul , div and mod 
do not apply to intensity arguments. 
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cat - string concatenation 

cat accepts two string arguments and returns the concaten- 
ation of the first onto the second. 

loc - point location 

loc accepts two integer arguments and returns the defined 
point . 

Usage - loc(x,y) where x is the x coordinate integer and 
y is the y coordinate integer. 

area - rectangle definition 

area accepts two unordered point arguments and returns the 
defined rectangle. 

inrct - point in rectangle 

inrct accepts a point and a rectangle argument, checks if 
the point is inside the area of the rectangle, and 
returns the boolean result. 

Usage - inrct (p,r) where p is a point and r is a rectangle. 

intrct - rectangle intersection 

intrct accepts two rectangle arguments and returns the 
intersection rectangle. 

putrct - put rectangle at 

putrct accepts a point and a rectangle argument and returns 
the rectangle with the same area as the input and its 
origin at the point argument. 

Usage - putrct (p,r) where p is a point and r is a rectangle. 

mapsp,mapps - conversion operators 

These operators convert points between point coordinates 
and font spot coordinates. They accept a point and a font 
argument and return a point. mapsp takes a spot coordinate 
and based on the font size returns its origin point, e.g., 
the origin point of spot (2,3) for a 10 by 10 font is 
point (20,30) . mapps takes a point and returns the font 
spot that it falls inside, e.g., the point (21,31) for a 
10 by 10 font is in spot (2.3) . 

Usage : 

- mapsp (f,p) where f is a font and p is a point, 

- mapps (f,p) where f is a font and p is a point. 
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gcolor - get color 

gcolor accepts a point and a form argument and returns the 
form's color at that point. 

Usage - gcolor (p,f) where p is a point and f is a font, 
fill - fill the form 

fill accepts a color and a form and returns the from with 
all its points set to the color argument. 

Usage - fill(c,f) where c is a color and f is a font. 

sblts , sbltd , sbltc - set ptblt rectangles 

These operators accept a rectangle and a ptblt argument 
and return the ptblt with the specified rectangle set to 
the rectangle argument. 

sblts sets the source, sbltd sets the detaintion, and 
sbltc sets the clipping rectangle. 

Usage - sblt_(r,b) where r is a rectangle and b is ptblt. 
sbltr - set ptblt rule 

sbltr accepts a natural and a ptblt argument and returns 
the ptblt with copy rule set to the natural argument. 

Usage - sbltr (n,b) where n is a natural and b is ptblt. 
infnt - is icon in font 

infnt accepts a natural and a font argument and returns 
a boolean result based on whether the icon indexed by the 
nautral argument is defined. 

Usage - infnt (n,f) where n is a natural and f is a font, 
dfnt - delete icon 

dfnt accepts a natural and a font argument and returns the 
font with the indexed icon deleted. 

Usage - dfnt(n,f) where n is a natural and f is a font, 
gfnt - get icon 

gfnt accepts a natural and a font argument and returns 
the form of the icon indexed. 

Usage - gfnt(n,f) where n is a natural and f is a font, 
un - union of lists 

un accepts two lists as arguments and returns the union 
of both. 
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int - intersection of lists 

int accepts two list arguments and returns the intersec- 
tion of both. 

cat - list concatenation 

This operator accepts two list arguments and returns the 
concatenation of the first list onto the second. 

get - get a list 

get accepts two list arguments and returns the list from 
the first argument that corresponds with the second. If 
any of the two arguments is the empty list the operation 
results in an error. 

de - delete a list 

This operator accepts two list arguments and returns a 
list that is equal to the second argument but reduced by 
the list indicated by the first argument. It is an error 
to apply de to an empty list or to specify a first argu- 
ment that is not contained in the second. 

retobj - retrieve an object 

retobj accepts two list arguments and returns the list 
that corresponds to the second argument. If the second 
argument is the empty list the result will also be the 
empty list. 

14.3.3. Triadic Operators (TOP's) 
dcolor - define color 

dcolor accepts three intensity arguments and returns the 
defined color. 

Usage - dcolor (r, g,b) where r is the red intensity, g is 
the green intensity, and b is the blue intensity. 

pof f st 

poffst accepts a point and two integer arguments and 
returns the point that is offset from the point argument 
by the integer arguments . 

Usage - pof f st (x , y , p) where x and y are the offset 
integers and p is the reference point. 

sftrct - shift rectangle 

sftrct accepts a rectangle and two integer arguments and 
returns the rectangle formed by offsettting its origin 
by the integer arguments . 
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Usage - sf tret (x, y , r) where x and y are the offset inte- 
gers and r is the reference rectangle. 

scolor - set color 

scolor accepts a color, a point and a form argument and 
returns the form with its point argument set to the color 
argument . 

Usage - scolor (p , c , f) where p is the point, c is the 
color, and f is the font. 

invfrm - inverse form 

invfrm accepts a form and two color arguments and returns 
the form with its fore and background colors inversed 
by the color arguments. 

Usage - invf rm ( f g , bg , f rm) where fg is the new foreground 
color, bg is the new background color, and frm is the form 
to be inversed. 

sfnt - set font 

sfnt accepts a natural, a form, and a font and returns the 
font with the new icon inserted that is defined by the 
form and natural arguments. 

Usage - sfnt ( frm, n , fnt) where frm is the icon form, n is 
the index, and fnt is the font. 

mod - modify list 

mod accepts a dblist, an objlist, and a pvallist and 
returns the dblist with the new pvallist inserted into 
the appropriate position of the objlist identified by the 
corresponding 'pid,' It is an error to apply a pvallist 
to an object for which it is not defined. 

14.3.4. Quadadic Operators (OOP's) 

fof f st - font offset 

foffst accepts two integer arguments as an offset, a point 
argument and a font argument. It returns the spot origin 
point based on the spot coordinate offset from the point 
argument, e.g., a font size of 10 by 10 which is offset 
2,3 from point (5,5) returns the spot origin point at 
(25,35) . 

Usage - fof f st (x , y , f nt , p) where x and y are the offset 
integers, fnt is the basis font, and, p is the reference 
point - 
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cpfrm - form copyblt 

cpfrm merges a source and a mask form with a destination 
form using the parameters in ptblt. It accepts a ptblt 
and three form arguments and returns the resultant form. 

Usage - cpf rm (pb , s ,m, d) where pb is the governing ptblt, 
s is the source form, m is the mask form, and d is the 
destination form. 

14.3.5. Sexadic Operators (SOP's) 
drawln - draw line 

drawln draws a line from point y to point z on the destina- 
tion form, using the specified brush and mask forms. It 
accepts two point arguments, three form arguments and a 
ptblt argument and returns a form. 

Usage - drawln (x ,y , pb , b ,m, d) where y is the start point, 
z is the end point, pb is the ptblt, b is the brush form, 
m is the mask form, and d is the destination form. 

cpfnt - copy font 

cpfnt copies a font icon to a designated point on the des- 
tination form. It accepts a natural and a font argument 
which defines the source form, a point argument for the 
target location, two form arguments and a ptblt argument 
and returns the resultant form. 

Usage - cpfnt (p ,pb ,n , fnt ,m , d) where p is the target location 
pb is the ptblt, n is the font index; fnt is the font, m 
is the mask form, and d is the destination form. 

14.3.6. Octadic Operators (OOP's) 
invfnt - inverse font 

invfnt performs the same operation as cpfnt except that 
the font icon is combined with inverse coloring. It 
accepts the same arguments plus two color arguments and 
returns the resultant form. 

Usage - invf nt ( fg ,bg , p , pb, n , f nt , m, d) where fg is the new 
foreground color, bg is the new background color, p is 
the target location, pb is the ptblt, n is the font index, 
fnt is the font, m is the mask form, and d is the destina- 
tion form. 

14.3.7. Relational Operators (ROP's) 

The relational operators are: 

== - equality 

> - greater than 



314 



>= - greater than or equal to 

< - less than 

<= - less than or equal to 

!= - not equal to 

They may be applied to int, nat, char, string, intens, pnt , 
and 1st. 

If == or != are applied to arguments of different types, 

== returns false, != returns true. This applies also to types 
not listed above. >,>=,< and <= return an error if their 
arguments are not of the same type. 

Relational operators return a boolean result. 

14.3.8. Test Operators (BOP's) 

These operators permit the programmer to test a cell for 
type before attempting to access it. These are necessary be- 
cause AM considers it a fatal error to read from an undefined 
cell or apply an operator of one type on data of another. 

The test operators are the same as the type mnemonics, plus a 
mnemonic for testing undefined values: 

bool 

nat 

int 

char 

string 

intens 

color 

pnt 

ret 

form 

font 

ptblt 

instr 

addr 

file 

undef 

pid 

val 

pval 

obj 

db 

1st 

Test operators accept a typed value and return true if the 
value is of the specified type, false otherwise. undef re- 
turns true if a value is undefined, false otherwise. 
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OFFSET 



Offset an Address 



OFFSET 



Syntax : 

offset I,R 

R must contain a memory address value 

Operation : 

R + I — > R 

Description : 

The sum of I and the address in R is stored in R. 
Example : 



offset 20 ,r (0 : 0) 

Addressing Modes: 

I: a 
R: r 



Format : 

! 0250 



|T] ; 3810 



] operands 



l 
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LINK 



Link Frame and Allocate 



LINK 



Syntax : 

link R , N 

Operation : 

R@ --> address® 
address --> R 



Description: 

A segment of N cells is allocated from the heap. The 
value stored in R is save at the base address of the segment. 
The segment base address is returned in R. 

This instruction is designed to create dynamic links for 



local environments. 




Example: 






proc : 


link 


r (0:5) ,1 




move 


r (0:5) 2@4,r(0:0) 




add 


{ int ,100} , r ( 0 : 0 ) 




move 


r (0:0) , r ( 0 : 5 ) 2@4 




unlink 


r (0:5) 




rts 





Above is an example of uplevel addressing. 
Addressing Modes: 



R: r 
N: a 



Format : 



0250 



in 



3811 



operands 
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UNLINK 



Unlink and Free 



UNLINK 



Syntax : 

unlink R 

Operation : 

R0 — > R 

Description : 

The value in the base address of the segment pointed to 
by R is returned in R. The segment is freed. 

Example : 

proc : 



link 


r ( 0 : 5 ) ,1 


move 


r (0:5) 2 @4 , r ( 0 : 0 ) 


add 


{ int , 100 } , r ( 0 : 0 ) 


move 


r (0:0) , r ( 0 : 5 ) 2 @4 


unlink 


r (0:5) 


rts 





Addressing Modes: 

R : r 

Format : 

0250 | pp] I 2812 



operand 



318 



GDWIN 



Get Display Window Location 



GDWIN 



Syntax : 

gdwin D,R 

Operation : 

D — > R 

Description : 

The value of the display window origin point at D is 
stored in R. 

Example : 

gdwin d ( 0 : 0 ) , r ( 0 : 0 ) 

Addressing Modes: 

R: r 

Format : 

0250 j \TJ 



3 8 1 3 | operands 
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SDWIN 



Set Display Window Location 



SDWIN 



Syntax : 

sdwin R,D 

R must contain a point value 

Operation : 

R — > D 

Description : 

The display window origin point at D is set to the point 
value in R. 

Example : 

sdwin r(0:0),d(0:0) 

Addressing Modes: 

R: r 

Format : 

! 0250 1 [P] 



3814 | \ operands 
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GMTR 



Get Monitor Attribute 



GMTR 



Syntax : 

gmtr T , R 

Operation: 

T — > R 



Description : 

The T value is stored in R. 
Example : 



gmtr -b,r(0:0) 

Addressing Modes: 

R: r 



Format: 



0250 



P 



2815 



281C 



operand 



321 



SMTR 



Set Monitor Attribute 



SMTR 



Syntax : 

smtr R,T 

R must contain a value appropriate for the selected 
attribute . 

Operation : 

R — > T 



Description : 

The T value is set to the value in R 
Example : 

smtr r ( 0 : 0) , -d 

Addressing Modes: 

R: r 



Format: 



0250 1 \T] { | 2 8 ID . . . | 2824 | } | operand 
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MONADS 



Monadic Short 



MONADS 



Syntax : 

<mop> C 

where : 

<mop> is a monadic operator 

Operation : 

<mop> C — > C 

Description : 

The operator corresponding to mop is applied to 
the result stored in C. 

Example : 

not r ( 0 : 0 ) 

Addressing Modes: 

C : r , d 

Format : 



0250 


[¥] | 3830 




operand 



and 
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MONADL 



Monadic Long 



MONADL 



Syntax : 

<mop> Cx,Cy 

where : 

<mop> is a monadic operator 

Operation : 

<mop> Cx — > Cy 

Description : 

The operator corresponding to <mop> is applied to Cx and 
the result stored in Cy . 

Example : 

not r.(0 : 0) , r (1 : 0) 
farea d(0:0),r(0:0) 

Addressing Modes: 

Cx : r , d 
Cy : r , d 

Format : 



0250 




P 




4831 


operands 
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MONADLI 



Monadic Long Immediate 



MONADLI 



Syntax : 

<mop> V,C 



where : 

<mop> is a monadic operator 

Operation : 

<mop> V --> C 

Description : 

The operator corresponding to <mop> is applied to the 
immediate value V and the result stored in C. 

Example : 

not { addr , flag} , r ( 1 : 0 ) 

newfrm ' { addr , rctsize} , d (0 : 0 ) 

Addressing Modes: 

V: i 
C : r , d 



Format : 



! 0250 




4832 



! operands 
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DYADS Dyadic Short 

Syntax: 

<dop> Cx,Cy 

where : 

<dop> is a dyadic operator 

Operation : 

Cy <dop> Cs — > Cy 

Description : 

The operation corresponding to <dop> is applied to the 
operands and the result stored in Cy . 

Example : 



and r (0 : 0) , r (0 : 1) 
fill r (0:0) ,d(0:0) 

Addressing Modes: 

Cx : r , d 
Cy : r , d 



Format : 



0250 



IH 



4833 | 



operands 



DYADS 
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DYADS I 



Dyadic Short Immediate 



DYADS I 



Syntax: 

<dop> V,C 



where : 

<dop> is a dyadic operator 

Operation : 

C <dop> V — > C 

Description : 

The operation corresponding to <dop> is applied to the 
operands and the result stored in C. 

Example : 



sub { int , 100 } , r (0 : 1 ) 

fill {color, & (10,10,10) } ,d(0:0) 

Addressing Modes: 

V: i 
C : r , d 



Format : 



0250 | | ~P~f | 4 834 | | operands 
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DYADL 



Dyadic Long 



DYADL 



Syntax : 

<dop> Cx,Cy,Cz 



where : 

<dop> is a dyadic operator 

Operation : 

Cy <dop> Cx --> Cz 

Description : 

The operation corresponding to <dop> is applied to Cx and 
Cy and the result stored in Cz. 

Example : 



add r (0:0) ,r(0:l) ,r (0:3) 
gcolor r(0:0),d(0:0),r(0: 1) 

<dop> Cx,Cy,Cy is equivalent to <dop> Cx,-Cy 



Addressing Modes: 



Cx: r,d 
Cy : r , d 
Cz : r,d 

Format : 



0250 



IH 



4835 



operands 



DYAD LI 



Dyadic Long Immediate 



DYADLI 



Syntax: 

<dop> V,Cx,Cy 

where : 

<dop> is a dyadic operator 

Operation : 

Cx <dop> V --> Cy 

Description : 

The operation corresponding to <dop> is applied to V and 
Cx and the result stored in Cy. 

Example : 

add {int , 100 } , r (0 : 0) , r (0 : 1) 
gcolor {pnt, (0,0) } ,d (0 : 0) , r (0 : 0) 

<dop> V,Cx,Cx is equivalent to <dop> V,Cx 

Addressing Modes: 

V: i 
Cx : r , d 
Cy : r , d 

Format : 



0250 | 


P 




4836 
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TRIADS 



Triadic Short 



TRIADS 



' Syntax : 

<top> Cx,Cy,Cz 

where : 

<top> is a triadic operator 
Operation : 

<top> Cx,Cy,Cz — > Cz 
Description : 

The operation corresponding to <top> is applied to the 
operands and the result stored in Cz . 

Example : 



sfnt r (0 : 0 ) , r ( 0 : 1) , r (0 : 2 ) 



Addressing Modes: 

Cx : r , d 
Cy : r , d 
Cz : r , d 

Format : 

0250 | | T] | 4837 



operands 
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TRIADL 



Triadic Long 



TRIADL 



Syntax : 

<top> Cw,Cx,Cy,Cz 
where : 

<top> is a triadic operator 
Operation : 

<top> Cw,Cx,Cy --> Cz 
Description : 

The operation corresponding to <top> is applied to the 
operands and the result stored in Cz. 

Example : 

sco lor r(0:0) , r (0 : 1) , d ( 0 : 2) , r ( 0 : 3 ) 
Addressing Modes: 



Cw : 


r,d 


Cx : 


r ,d 


Cy : 


r,d 


Cz : 


r,d 


Format : 





0250 j |TJ 



4838 1 operands 
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QUADS 



Quadic Short 



QUADS 



Syntax : 

<qop> Cw,Cx,Cy,Cz 
where : 

<qop> is a quadadic operator 
Operation : 

<qop> Cw,Cx,Cy,Cz --> Cz 
Description : 

The operation corresponding to <qop> is applied to the 
operands and the result stored in Cz . 

Example : 



cpfrm r (0 : 0) ,d (0 : 0) , r (0 : 1) , d (0 : 1) 

Addressing Modes; 

Cw : r , d 
Cx ; r , d 
Cy : r , d 
Cz : r ,d 

Format : 



0250 | |Tf 


4 839 




operands 
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QUADL 



Quadic Long 



QUADL 



Syntax: 

<qop> Cv,Cw,Cx,Cy ,Cz 
where : 

<qop> is a quadadic operator 
Operation : 

<qop> Cv,Cw,Cx,Cy — > Cz 
Description : 

The operation corresponding to <qop> is applied to the 
operands and the result stored in Cz. 

Example : 



cpf rm r ( 0 : 0 ) , r ( 0 : 1 ) , r ( 0 : 2 ) , r ( 0 : 3 ) , d ( 0 : 0 ) 



Addressing Modes: 



Cv: 


r , d 


Cw : 


r,d 


Cx : 


r ,-d 


Cy : 


r,d 


Cz : 


r,d 


Format : 





0250 



m 



4 83A 



operands 
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SEXADS 



Sexadic Short 



SEXADS 



Syntax : 

<sop> Cu,Cv,Cw,Cx,Cy ,Cz 



where : 

<sop> is a sexadic operator 
Operation : 

<sop> Cu , Cv , Cw , Cx , Cy , Cz — > Cz 
Description : 

The operation corresponding to <sop> is applied to the 
operands and the result stored in Cz . 

Example : 



drawln r(0:0) , r ( 0 : 1 ) , r ( 0 : 2 ) , r ( 0 : 3 ) , r ( 0 : 4 ) , d ( 0 : 0 ) 



Addressing Modes: 



Cu: 


r , d 


Cv : 


r,d 


Cw : 


r , d 


Cx : 


r , d 


Cy : 


r , d 


Cz : 


r , d 


Format : 





0250 I ITT ! 4 83B | 



operands j 



SEXADI 



Sexadic Long 



SEXADL 



Syntax : 

<sop> Ct,Cu,Cv,Cw,Cx,Cy ,Cz 
where : 

<sop> is a sexadic operator 
Operation : 

<sop> Ct,Cu,Cv,Cw,Cx,Cy — > Cz 



Description : 

The operation corresponding to <sop> is applied to the 
operands and the result stored in Cz . 

Example : 

cpfnt r ( 0 : 0 ) , r ( 0 : 1) , r ( 0 : 2 ) , r ( 0 : 3) , r ( 0 : 4 ) , 
d ( 0 : 0 ) , d ( 0 : 1 ) 

Addressing Modes: 



Ct : 


r,d 


Cu : 


r ,d 


Cv: 


r,d 


Cw : 


r,d 


Cx: 


r,d 


Cy : 


r ,d 


Cz : 


r , d 


Format : 





0250 


1 PT 


4 8 3C 




operands 
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OCTADS 



Octadic Short 



OCTADS 



Syntax : 

<oop> CsCt,Cu, Cv,Cw,Cx,Cy ,Cz 
where : 

<oop> is a octadic operator 
Operation: 

<oop> Cs , Ct , Cu , Cv , Cw, Cx , Cy , Cz --> Cz 
Description : 

The operation corresponding to <oop> is applied to the 
operands and the result stored in Cz. 

Example : 

invfnt r(0:0) ,r(0:l) , r ( 0 : 2 ) , r ( 0 : 3 ) , r ( 0 : 4 ) , r ( 0 : 5 ) , 
r ( 0 : 6 ) , d ( 0 : 1) 

Addressing Modes: 

Cs: r,d 
Ct: r , d 
Cu: r,d 
Cv : r , d 
Cw : r , d 
Cx : r , d 
Cy : r ,d 
Cz : r , d 

Format : 



| 02 50 | |"PT | 4 83D | j operands 



OCTADL 



Octadic Long 



OCTADL 



Syntax : 

<oop> Cr , Cs , Ct , Cu , Cv, Cw, Cx, Cy , Cz 
where : 

<oop> is a octadic operator 
Operation : 

<oop> Cr,Cs,Ct ,Cu,Cv,Cw,Cx,Cy — > Cz 
Description : 

The operation corresponding to <oop> is applied to the 
operands and the result stored in Cz. 



Example : 

invf nt r(0:0) , r ( 0 : 1 ) , r ( 0 : 2 ) ,r(0:3) , r ( 0 : 4 ) , r ( 0 : 5 ) , 
r (0:6) ,d(0:0) ,d(0:l) 



Addressing Modes: 



Cr : 


r 


Cs : 


r 


Ct : 


2T 


Cu: 


r 


Cv: 


r 


Cw : 


r 


Cx: 


r 


Cy: 


r 


Cz : 


r 


Format : 





I 0250 



d 

d 

d 

d 

d 

d 

d 

d 

d 

|TT ] ~T83E 



operands j 
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MOVE 



Move a Value 



MOVE 



Syntax : 

move <eal>,<ea2> 
where : 

<ea> must be one of the addressing modes listed below 
Operation : 

source — > destination 
Description : 

The value found at the source address is copied into 
the destination address. 



Example : 

move r ( 0 : 0 ) ,d(0:0) 
move d(0:l),r(0:4) 
move r ( 0 : 0 ) , data 
move { addr , data} , r ( 0 : 2 0 ) 
move { int , 100 } , r ( 0 : 20 ) @ 
move r(O:2O)01O,r(O:lO) 

data: ds 100 



Addressing Modes: 

<eal>: d , r , ri , rid , ridn ,m , per , i 
<ea2>: d , r , ri , rid , ridn , m, per 



Format : 



0250 | | ~Pj { | H 8 5 0 | . . . | H884 | } | operands 
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PUSH 



Push a Value 



PUSH 



Syntax : 

push <ea>,S 

where : 

<ea> is one of the addressing modes listed below 

Operation : 

source — > S 

Description : 

The source value is pushed onto stack S. The programmer 
has no access to the stack pointer. 

Example : 



push { int , 100 } , s ( 0 ) 
push r (0 : 10) , s (1) 
push d (0 : 0) , s (1 ) 



Addressing Modes: 

<ea>: d ,m, per , r , ri , rid , ridn , i 
S: s 



Format : 



02 50 | |~Fj{| H8 8~0~f . . . | H 8 8 7 | }| operands 
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POP 


Pop a Value POP 


Syntax : 

pop S,<ea> 

where : 





<ea> is one of the addressing modes listed below 

Operation : 

S --> destination 

Description : 

The source value is popped off stack S and stored at <ea>. 
The programmer has no access to the stack pointer. 

It is an error to attempt to pop a value from an empty 



stack . 
Example : 






pop s ( 0 ) , r ( 0 : 1 ) 
pop s (0) ,data 
pop s (1) ,d(0 : 0) 


data : 


ds 1 



Addressing Modes: 

S : s 

<ea>: d , m, per , r , ri rid , ridn 
Format : 

! 02 50 | | ~P~f { | H 8 8 9 j . . . | H 8 8 f | } | operands 
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POPX 



•Remove the Top of a Stack 



POPX 



Syntax : 

popx S 

Operation : 

S --> 

Description ; 

The top value of stack S is removed. 

It is an error to attempt to remove the top of an empty 
stack . 

Example : 

popx s(0) 

Addressing Modes: 

S , s 

Format : 



0250 


fpT 


2888 


operands 
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NOP 



No Operation 



Syntax : 
nop 

Operation : 

Description : 

Does nothing. 
Addressing Modes: 

Format : 



0250 | | ~P] 1 18A0 j 



STOP 

Syntax : 
stop 

Operation : 


Halt Execution STOP 


Description : 
Execution 


is terminated. 



Addressing Modes: 
Format : 

0250 1 |TJ 1 18A1 1 
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JMP 



Jump 



JMP 



Syntax : 

jmp <ea> 

where 

<ea> is one of the addressing modes listed below 

Operation : 

<ea> — > PC 

Description : 

Execution resumes at <ea>. 

If jmp follows a rorg directive, a jump to memory abso- 
lute is converted to a branch. 

Example : 

jmp here 
j mp r ( 0 : 0 ) 

here: jmp (1:150) (§ 

Addressing Modes: 

<ea>: m,r,mi,pcr 

Format : 

0250 j |TJ (| H8A2 ' . . . 



H8 5A4 | }| operands 
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BRA 



Branch 



BRA 



Syntax : 

bra <ev> 

where : 

<ev> is one of the addressing modes listed below 

Operation : 

PC + <ev> — > PC 

Description : 

Execution resumes at the sum of the program counter and the 
effective value. 

Example : 



bra 100 

Addressing Modes: 

<ev>: a f r 



Format : 



0250 | !]PT 


H8A5 


• . • 


H8A6 


} operands 
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IF 



IF: Conditional Jump/Branch 



IF 



Syntax : 

if R <rop> <ev>,M 
if <bop> <ea>,M 

where : 

<rop> is a relational operator 
<bop> is a test operator 

<ea> and <ev> are one of the addressing modes listed below 
Operation : 

if R <rop> <ev> then 
M — > PC 

if <bop> <ea> then 
M — > PC 



Description : 

If the comparison is true, execution resumes at M; other- 
wise, with the next instruction. 



Example : 





move 


{int,10} ,r (0:0) 


loop: 


if 


r(0:0) < {int,l},done 




sub 


{ int , 1 } , r ( 0 : 0 ) 




jmp 


loop 


done : 


if 


int data, loop 


data 


ds 


1 



Addressing Modes: 
R : r 

<ev> : r,i 
<ea>: r,m 
M: m,pcr 



Format : 



0250 1 |TJ 



{ ' 58A7 



operands 



5 SAB 


f 


58 AC 


t 


4 8AF 


t 


4 8B0 


t \ 


48B3 


f 


48B4 
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IFTE 



If-Then-Else : Conditional Jump/Branch 



IFTE 



Syntax : 

if R <rop> <ev>,Mx,My 
if <bop> <ea>,Mx,My 

where : 

<rop> is a relational operator 
<bop> is a test operator 

<ea> and <ev> are one of the addressing modes listed below 
Operation : 

if R <rop> <ev> then 



Mx — > 


PC 


else 




My — > 


PC 


if <bop> <ea> 


then 


Mx — > 


PC 


My — > 


PC 



Description : 

If the comparison is true, execution resumes at Mx; 



otherwise , 


at My. 




Example : 




if 


n 

o 

o 

V 

h 
o 
( — 1 


stuff : 


move 


r ( 0 : 0 ) , data 


easel : 


j sr 


first, s (0) 




if 


int r ( 0 : 0 ) , easel 


case2 : 


stop 

jsr 


second, s ( 0) 


Addressing 


stop 
Modes : 





R: r 

<ev>: r,i 
<ea>: r,m 
Mx: m,pcr 
My: m,pcr 
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Format : 



0250 j |TJ 



{ | 6 8A9 | , | 6 8AA | , j 6 8 AD j , | 6 8AE j , [ 58B1 | , | 58B2 | , | 58B5 

| operands 



58B6 
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JSR 



Jump Subroutine 



JSR 



Syntax : 

jsr <ea>,S 

where : 

<ea> is one of the addressing modes listed below 

Operation : 

PC — > S 
<ea> — > PC 

Description : 

The program counter is pushed onto stack S, and execu- 
tion resumes at <ea>. 

Following a rorg directive, memory absolute is converted 
automatically to program counter relative. 

Example : 

jsr incr,s(0) 

Addressing Modes: 

<ea>: m , mi , r , per , S : s 

Format : 



0250 


\~P] { H8B7 


» . . 


H8B9 | } 1 operands 
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BSR 



Branch Subroutine 



BSR 



Syntax : 

bsr <ev>,S 

where : 

<ev> is one of the addressing modes listed below 

Operation : 

PC — > S 

PC + <ev> — ■> PC 



Description : 

The program counter is pushed onto stack S, and execu- 
tion resumes at the sum of the program counter and <ev>. 

Example : 

bsr r ( 1 : 0 ) , s ( 0 ) 



Addressing Modes: 
<ev>: r,a S: s 



Format : 



! 0250 




38BA 



3 8 BB 



operands 
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RTS 



Return from Subroutine 



RTS 



Syntax : 

rts S 

Operation : 

S — > PC 

Description : 

Execution resumes at the address popped from stack S. 
Example : 

incre: add { int , 1 } , r ( 0 : 0 ) 

rts s(0) 

Addressing Modes: 

S : s 

Format : 

0250 j |TJ j 28BC 



operand 
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OPEN 



Open a File 



OPEN 



Syntax : 

open S 

Operation : 

S — > 

Description : 

To open a file, four file parameters must be pushed on 
the stack, in proper order, before the open instruction is 
invoked. These attributes are: a string atom for the 

filename, a file descriptor atom, an integer atom for the 
access mode, and an integer atom for the data type (raw or 
AM typed values) . The open instruction pops these parameters 
off the stack and opens the file. All future file operations 
are referenced by the file descriptor. 

Example : 

datafile equ {file, 3} 

push { string fi lename" }, s ( 0 ) 

push {dataf ile } , s ( 0 ) 

push { int , 0 } , s (0 ) 

push { int , 0 } , s ( 0 ) 

open s ( 0 ) 



Addressing Modes: 

S : s 

Format : 

j 0250 | |Tj | 28C0 | | operand 
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CLOSE 



Close a File 



CLOSE 



Syntax: 

close S 

Operation : 

S — > 

Description : 

The file descriptor atom must first be pushed on the stack. 
The close instruction pops the stack and closes the file. 



Example : 

datafile 



equ {file, 3} 
push { datafile }, s ( 0 ) 
close s(0) 



Addressing Modes: 
S : s 

Format : 



0250 


' IS 


2 8C1 




operand 
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READ 



Read a File 



READ 



Syntax : 

read S 

Operation : 
S — > 



Description : 



The file descriptor atom must first be pushed on the stack. 
The memory address atom for the destination buffer cell is 
pushed next. The read instruction pops these parameters off 
the stack and puts the next file cell in the destination 
buffer . 



Example : 



datafile 


equ 


{file, 3} 




push 


{datafile } , s ( 0) 




push 


{ addr , data } , s ( 0 ) 




read 


s ( 0 ) 


data 


ds 


100 



Addressing Modes: 
S : s 



Format : 



0250 j |TJ 1 28C2 



operand] 
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WRITE 


Write to File WRITE 


Syntax : 

write S 

Operation : 

S — > 

Description : 





The file descriptor atom must first be pushed on the stack 
The memory address atom for the source buffer cell is pushed 
next. The write instruction pops these parameters off the 
stack and puts the contents of the source buffer cell into 
the next file cell. 



Example : 

datafile. 

data 


equ {file ,3} 

push (datafile) , s (0 ) 
push {addr ,data) , s (0) 
write s ( 0 ) 

dc {string, "hello world") 



Addressing Modes: 
S : s 



Format : 

! 0250 | fpT 


28C3 | j operand | 
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WRITE 



Write a Value to the Queue 



WRITE 



Syntax : 

write<ea> , Q 

where : 

<ea> is one of the addressing modes listed below 

Operation : 

Source — > Q 

Description : 

The source value is written onto queue Q. The programmer 
has no access to the queue pointer. 

Example : 

write { nat . 17 } , q ( 0 ) 
write r (0 : 10) , q (.1) 

Addressing Modes: 

<ea> : m,r,i,q 

Q • q 



Format : 

1 0250 



I P] { 



H 8 9 0 



H897 





operands 
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READ 



Read a Value from the Queue 



READ 



Syntax: 

read Q,<ea> 



where 

<ea> is one of the addressing modes listed below 

Operation : 

Q --> destination 

Description : 

The source value is read from the queue Q and stored at 
<ea>. The programmer has no access to the queue pointer. 

It is an error to attempt to read a value from an empty queue. 



Example : 

read q (0 ) , r ( 0 : 1 ) 
read- q (0) ,data 
data: dsl 

Addressing Modes: 

Q: q 

<ea> : m,r 



Format : 
0250 



fp] { | H899 



H89 f 



operands 
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DELETE 



Delete the Front Value of the Queue 



DELETE 



Syntax : 

delete Q 

Operation : 

Q — > 

Description : 

The front value of queue Q is removed. It is an error 
to attempt to remove the front value of an empty queue. 

Example : 



delete q(0) 

Addressing Modes: 

Q: q 



Format : 



0250 



in 



2898 



operands 



3 58 



OPEN 



Open the Database 



OPEN 



Syntax : 

open D 

Operation : 

D — > 

Description : 

A database identifier is required to open the databse. 
All future operations are referenced by this identifier. 

Example : 



open {database ,databaseid} 



Addressing Modes: 
D: i 



Format : 



0250 



IH 



28C4 1 



operand 



% 
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CLOSE 



Close the Database 



CLOSE 



Syntax : 

close D 

Operation : 

D — > 

Description : 

The database identifier is required to close the database. 
Example : 

close {database , databaseid} 

Addressing Modes: 

D: i 

Format : 



0250 


|P| ! 28C5 




operand 



j*" 
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